Svalefelt Scheduler

The landing page after sign-in. The tiles count runs in the last hour, today and yesterday, with the failures called out in red; what is running right now; how many jobs exist and how many are enabled; and one tile per Nova batch server the scheduler watches, showing whether its heartbeat is answered and when it last was. Below, the latest runs and the latest failures. The failures table says which step failed and how - here the reconciliation that follows the bank export stopped at its reconcile step with exit code 3; the totals it printed are one click away in the run's log - so the failure is on the front page, not three clicks down. Every row opens the run's log.

One table per group - a group is just a word in the job file, used to keep a customer's or a system's jobs together - and one row per job: its description, when it last ran and how long that took, how it ended, and when it runs next. "Event-driven" means a file or a job trigger will start it; "after bank-file-export" is a job that follows another. Run appears only on jobs that have no trigger at all, the ones meant to be started by hand; every other job is started by its triggers, and the editor has a Run now for the rest. A disabled job is greyed. Clicking anywhere on a row opens the job in the editor. Jobs are YAML files in a folder: what you see here is the folder, read again the moment a file changes.

A job is read top to bottom: what it is, what starts it, what it does in order, what to do when something goes wrong, and the variables every step gets. Each trigger, step and handler is one line - the kind in bold, the step's name, and a description that is either written in the file or made from the settings (a file trigger shows the folder and pattern it watches; a script step shows its command) - with badges for a connection, a timeout or retries. Click a line to open it. The purple handlers run at the phase on their pill: this one answers stop when the load step fails, after paging the on-call engineer. The Run now button runs the saved file, the YAML tab shows the same job as text, and Validate runs the same checks the scheduler applies when it loads the file.

Every step kind has its own form, so a Nova INIT import asks for exactly what it needs: the file as the batch server sees it (${TRIGGER_FILE_NAME} inserts the file the trigger found), whether to verify the import against Nova's import log, whether zero imported records is acceptable, and which results are worth a retry (MUTEX and TIMEOUT by default - a missing file is not). Under the form, What this step can end with lists every outcome with its meaning: the batch server's own results (OK, FAILED, MUTEX, FILE_MISSING, TIMEOUT) and the verification's (OK, EMPTY, FAILED, NOT_FOUND), which is how a job can fail although Nova reported success - the import log has the last word. The retry and timeout settings and the output file check sit in their own folds.

Add step opens the catalogue of step kinds under their headings, each with a line saying what it does. The general kinds run a script, Python or SQL; the file kinds move data between folders and SQL Server tables; the Nova kinds each book one task on the Nova batch server and follow it to a verified result - the four built-in imports, an OB-code script, a program, and further down the batch tasks whose layouts were taken from live schedules (SQL definitions, printing, payment commits, ...). Any Nova task takes hand-written TaskData for anything else, and Start / stop the batch server controls the server itself. The same catalogue drives the forms and the validation: a setting the kind does not know is reported when the file is loaded, not when the job runs.

Handlers are how a job reacts to its own events without a wrapper script around it. They are one list; the Add handler menu asks in one click both when it runs - on start, on error, or finally - and what it is (script, Python or SQL). An on-error handler can be scoped to one step, to that step and everything after or before it, or to all but it, and can fire only on failures that would stop the job or only on those the job would continue past. It answers with a word - continue, restart-step, restart-job or stop - printed as SCHEDULER_RESULT= from a script or returned from a SQL query; the number of restarts is capped. The job file keeps the three lists onStart, onError and onFinally as before; only the editor shows them as one.

The YAML tab is the job file itself, in an editor with syntax colouring. Switching tabs converts through the scheduler's own parser and serializer, so the form and the running scheduler can never disagree about what a file means, and a file written by hand - or generated by scheduler nova convert from a Nova schedule - opens in the form like any other. Saving from the form rewrites the file and drops hand-written comments; the UI says so, and the YAML tab keeps them. Because the files are the truth, they live in version control like code: a change is a diff, a rollback is a checkout, and a second scheduler is a copy of the folder.

The log lists runs under Last hour, Earlier today, Earlier this week and Older, so the question "what happened since I left" is answered by the top of the page. Each row is the job, when it started, how long it took, how it ended and - for a failed run - why, as the failing step reported it. The list refreshes on its own while auto-refresh is on, fetching only the newest runs and merging them in; Flat turns it into one table, and the filters narrow it to one job or to failures only. Underneath, every run is one JSONL file on disk, which is what makes the log greppable from a shell and readable long after the UI is gone.

Clicking a run opens its log: every event the runner recorded, in order - the run starting, each step starting and ending with its duration and exit code, every line the step printed on stdout or stderr, the handlers that fired and what they answered, and the final status. Here the reconciliation's second step printed the two totals and their difference and then failed, the report step was never reached, and the finally handler still ran and said so. The same text is in the JSONL file under runs/<job>/<run id>.jsonl, and scheduler run <job> streams it to the console when a job is started from a shell.

The state page is where the reason for this scheduler shows. For every configured Nova system it sends a small job through the batch server at an interval - a heartbeat that is only ok when the server picked the job up, ran it and wrote the result, which a running service process alone does not prove - and keeps a strip of the recent beats with their latency; Send heartbeat now asks for one straight away. With a service or container configured it also shows the server's state and offers Start, Stop and Restart (the two that interrupt work ask first and are logged with the user's name), and it can be told to restart the server on its own after a number of failed heartbeats. In this picture the system is the real Nova batch server of the Wine test environment, answering from a container. Below, every folder and file the jobs refer to - watched folders, script files, output files, files on the batch server - is listed and checked read-only from this machine, so a share that moved is found before the job that needs it runs at night.

The version in the header is a link. It opens the release notes this build carries - the same text as docs/RELEASE-NOTES.md, embedded into the binary when the release was built, so a deployment can always say what it is and what changed. scheduler notes prints the same from a shell, and a release is refused when the notes say nothing about its version. The build id under the title carries the date and the commit.

Every page of the tour sits behind this box: the web UI opens on it. Today any name is accepted - the credential check is the one piece meant to be replaced by a real one - but everything behind the box is the real thing: the browser gets a short-lived access token and a rotating refresh token, every /api/* call carries the token, and a restart of the service means signing in again. The command line (scheduler run, validate, nova status, ...) never goes through this; it reads the job files and the configuration directly.