Dashboard

Every discovered schedule shows up in the Schedules panel of both the local DevTools dashboard (voltro dev) and the Voltro Cloud dashboard. Same component, two transports: DevTools polls the app's inspect endpoints directly; Cloud streams firing history live via its reactive bridge.

#What you see

Per schedule:

• Name, cron expression, timezone, and a live next-firing countdown ("in 4h 59m").
• Trigger badge — self or external.
• The effective coordination strategy for the app (single / advisoryLock / cluster), shown once at the top.
• overlap, backfill, and max runtime settings.
• A Run now button (capability-gated) — fires the handler immediately, bypassing the clock and coordination, recorded as a manual run.

Per firing (expand a schedule's run timeline):

• Status — succeeded, failed, skipped, missed, or running, each colour-toned.
• When it fired (relative + absolute), how long it took, and which replica ran it.
• The coordinationOutcome (single / wonLock / cluster / external) — why this instance ran it.
• For failures: the errorTag and message (e.g. SmtpError: connection refused, or timeout from the watchdog).

#Reading the statuses

Status	Meaning
succeeded	Handler completed within maxRuntimeMs.
failed	Handler threw, or the watchdog tripped (errorTag: timeout).
skipped	An overlapping firing under onOverlap: 'skip'.
missed	A firing skipped during downtime, recorded by backfill: 'latest'. Visible evidence of a gap, not a silent hole.
running	In flight right now.

missed and skipped rows matter: they're the system telling you a firing didn't run and why. A wall of missed after a deploy means your downtime crossed firing instants — expected with backfill: 'skip', a signal to consider latest if those runs mattered.

#"Run now"

The Run now button triggers the handler out-of-band. The run is tagged trigger: 'manual' and always executes regardless of onOverlap — operators expect the button to fire. Inside the handler you can branch on ctx.trigger === 'manual' to skip schedule-only guards (e.g. a weekday check) during a manual test.

It's gated on the same capability as workflow run-control, so read-only dashboard viewers see the history but can't trigger firings.

#The endpoints behind it

The dashboard is a thin client over the app's inspect API — useful if you're scripting:

GET  /_voltro/inspect/schedules            # discovered schedules + effective coordination
GET  /_voltro/inspect/schedules/runs?name= # firing history for one schedule
POST /_voltro/inspect/schedules/:name/fire # "Run now"

In the Cloud dashboard, firing history is live — the cloud API mirrors each app's inspect stream into a reactive cache, so new runs appear without a refresh. In local DevTools the panel polls every few seconds.

See workflow debugging for the analogous Workflows panel.