The five bands
Status, problems, running now, next up and failing lately — in the order the questions get asked, and as named things, never as counts.
The dashboard is the screen you land on: what is broken, what is running, what is coming. Five bands from the top down, in the order an operator asks the questions — and arranged so that the healthy state, in which a wall carrying a dashboard hangs most of the time, is the main one and does not look empty.
1 · Status
One row across the full width, always present. When all is well it is a calm sentence: all clear, the number of jobs, the number of agents online, and how many seconds ago that was checked. When it is not, the number of problems and the newest of them, spelled out. It is the only band that grows in kiosk mode; the others shrink beneath it.
2 · Problems
Problems is a list of named things that are wrong, each linking to the cause. Empty when there is nothing to say — and the emptiness is the point. Five kinds:
| Row | What it means |
|---|---|
| a job failed | its latest run is failed or orphaned |
| a job was never picked up | its latest run ended skipped — nobody took it |
| a job has nowhere to run | none of its agents is enabled and enrolled; such a job produces not even a row and looks idle |
| the queue is stuck | a run has been waiting for an agent longer than one missed poll explains |
| an agent is offline | a registered agent is not reporting in and jobs are aimed at it |
They sort by time, not severity: a wall exists to show what has changed, and sorting by severity buries a new fault under a known one. Chronic failures collapse into one row with a window. A disabled job is not a problem: disabling is deliberate, and this list reports the unexpected, not the configured. Nor is an offline agent with no jobs — an idle machine that has gone quiet is not an incident.
3 · Running now
Running now: active runs across jobs, with elapsed time, the agent and a link into the output. The only band with a legitimate claim to refreshing quickly.
4 · Next up
Next up: the next eight or so different jobs — each at most once, so a minutely job takes one row rather than eight — with a countdown ticking in the browser from fixed times. The times come from the running scheduler, not from cron re-parsed in the browser: the scheduler knows what is actually registered, honours Enabled and the workspace's timezone, and a second implementation of cron would quietly drift away from it. Which is why a disabled job is not here.
5 · Failing lately
Failing lately: the last twenty-five or so runs per job as a row of coloured squares. Healthy jobs are not in the list — their health is reported by the first band. Only jobs with a failure in the window, worst first; that is what lets the band survive a hundred jobs and fit on a wall.
Named things, never counts
A row always names a job or an agent, carries the moment it went wrong, and links to the cause. "3 failed" tells you to start looking; "backup-db failed on node-2" tells you where. Fleet-wide totals are deliberately not turned into rows: with no identity and no timestamp they could say nothing beyond the number they came from.
The window is a count of runs, not a span of time
Recurrence is written as 7 of last 25, never as "7 in 24 hours". Those two
numbers agree only for a job that runs hourly; for a minutely one, 24 hours is
1,440 runs, and for a weekly one it is not a single one.
Where the data comes from
Three of the bands cost not one extra request — jobs, agents and statistics are already being refreshed elsewhere and the dashboard only reads them. Two have a query of their own: the times of the next runs from the scheduler, and the states of the latest runs per job, in a compact shape and at a slower pace, because they change only when a run ends.