Scheduler reliability
Know when a schedule should have fired and did not.
The brain watches every enabled interval and cron schedule and flags a misfire when an expected fire slips past its grace window, the signal that a scheduler process has died or fallen behind. Manual fires are attributed to the operator who triggered them, so a fire-now always has a name against it. Fire history is retained through Postgres range-partitioning so a busy fleet keeps its record without bloating a single table, and fire-variance metrics surface how far actual fire times drift from their schedule.
Ships with
- Brain-side misfire detection: an enabled interval or cron schedule past its grace window is flagged
- Per-operator fire attribution: a manual fire-now records who triggered it
- Fire-history retention via Postgres range-partitioning
- Fire-variance metrics show drift between expected and actual fire times
- Misfires surface as an alerting trigger that feeds subscriptions and automation rules
- z4j misfires --project <slug> lists detected misfires from the CLI (--json for scripting)
Highlights
- A dead scheduler stops being a silent failure: the misfire is detected on the brain side
- Misfire and circuit-breaker-trip triggers plug straight into notifications and rules
- Fire attribution plus the audit chain together answer who fired what, and when
Related