A scheduler process has no user interface (UI). It runs in the background, looking for tasks that are scheduled to start. It then fires off a subprocess that runs that task, and records the results in the database. A normal HTTP request can add a task to the queue, or check the status of task. Tasks often do their work by "side effects": creating a file, sending email, changing values in a database table.
I have several tasks that generate email in response to an upload and automated scanning of the file. I also handle my session cleanup with a task. I keep an eye on tasks by using Appadmin or through the database console application (sqlite3 from the command line, or psql). On a system where Appadmin isn't set up,
select * from scheduler_task where status == 'QUEUED'; -- or 'FAILED' or 'COMPLETE'
select * from scheduler_run where id > (select max(id) from scheduler_run) - 5;
I don't recommend doing INSERT or UPDATE on the tables; using the API is much safer. The .schema should be considered implementation-dependent, rather than public.
One of the other things I use the Scheduler for is getting remote files. I do this for a "toy" server I use at home, running on my Windows 10 laptop. I open a command window, and do my -K there, and then ignore that cmd afterwards .. Windows doesn't have the foreground/background support in CMD that a Unix/Linux shell has.
I haven't used NSSM. I have set up a buildbot client using the built-in Windows task tools (schtasks /create and schtasks /run with an appropriate xml file); those techniques should work for a Scheduler process, but I haven't tried that yet, as I haven't yet needed automatiion of starting the Scheduler process.