Concepts

deadpost watches for absence. Everything below is about one question: when should silence from a job be treated as a failure?

Schedules

A monitor expects a check-in on a schedule, and there are two ways to describe one.

Interval is the simple model: a ping is expected every period. A job that runs hourly gets a period of one hour, and the next deadline is always measured from the last check-in.

Cron takes the actual cron expression and a timezone, and expects a ping after each scheduled fire. Use it when the job doesn’t run at a fixed interval — 0 9,18 * * 1-5 fires twice on weekdays and not at all on weekends, which an interval cannot express without alerting all weekend.

Cron schedules are evaluated in the timezone you give them and are DST-aware, so a 09:00 job stays a 09:00 job across a clock change rather than drifting an hour twice a year.

When the schedule is wrong

Configured schedules drift away from reality. A job gets moved from hourly to every two hours and nobody updates the monitor; a cron line changes and the monitor keeps expecting the old cadence.

deadpost watches the actual gaps between check-ins and, when they consistently disagree with the configured period, raises a schedule suggestion: a proposed new period, the current one for comparison, how many pings it’s based on, and a confidence score.

You can accept it — which updates the monitor’s period — or dismiss it. Dismissing is remembered, so the same suggestion doesn’t reappear every time the job runs.

This matters because a monitor with a stale schedule fails in the quiet direction. If the job now runs half as often, the monitor is late constantly until someone widens the grace to shut it up — and a monitor with an absurdly wide grace window has stopped monitoring anything.

Period and grace

The period is when you expect the ping. The grace window is how much lateness is normal before it means something.

Grace exists because almost nothing runs to the second. A backup scheduled hourly might start at :00 and take two to six minutes depending on load. With no grace you’d be paged every time it took longer than usual; with an hour of grace you’d learn about a real outage an hour late. Set it to a little more than the job’s worst normal run.

Two deadlines follow from this:

• Period deadline — when the ping was expected.
• Grace deadline — period deadline plus grace, after which the job is considered down.

Monitor states

There are five, and a monitor is always in exactly one.

State	Meaning
pending	Created (or just resumed) and waiting for its first check-in. Nothing is judged yet.
healthy	The last check-in arrived on time.
late	Past the period deadline, still inside the grace window. Not an alert yet.
down	Past the grace deadline. This is what alerts.
paused	Not being evaluated at all.

late is deliberately visible but quiet. It is the state that tells you a job is drifting — running slower each week, creeping toward its grace window — while there is still nothing wrong. Watching monitors sit in late more often is how you catch a problem before it becomes an outage.

A monitor goes pending → healthy on its first ping. From there it moves to late and then down as deadlines pass, and back to healthy the moment a check-in arrives.

Outages

When a monitor goes down, the period it stayed down is recorded as an outage — when it started, when it recovered, and how long that took. Outages are what you look at afterwards, when the question is “how bad was it?” rather than “is it broken now?”.

You can attach notes to an outage. This is the postmortem hook: what caused it, what was done, whether it’s expected to recur. A monitor that went down three times last month with three notes attached is a very different conversation from three bare timestamps — the notes are what let the next person read the history without reconstructing it.

Pause and snooze are different

They sound alike and do different things. Reaching for the wrong one is the most common way to end up either blind or paged.

Pause stops evaluation. The monitor’s clock stops. It does not go late, it does not go down, and no deadline is being tracked at all. Use it when the job genuinely isn’t supposed to run — decommissioned, or disabled for a migration. Resuming puts the monitor back in pending, waiting for a first check-in rather than assuming the last one is still current.

Snooze suppresses alerts while evaluation continues. The monitor still goes late and still goes down; you just don’t get told. Use it when you already know something is broken and don’t want to be paged about it every escalation while you fix it. When the snooze expires, alerting resumes with the monitor in whatever state it actually reached.

Pausing a broken monitor to stop the noise also stops the monitoring — and when the fix lands, nothing tells you whether it worked.

Snoozing keeps the record honest.

A snooze can be set for a duration, until a specific time, or indefinitely.

Quiet hours

Quiet hours are a daily window — a start time, an end time and a timezone — in which a monitor won’t wake you.

The important detail is that quiet hours defer an alert rather than discarding it. A job that goes down at 02:00 inside a 22:00–08:00 window does not vanish; the alert is scheduled to arrive when the window ends. You still find out, at a time when you can act on it.

That is the difference between quiet hours and snooze. Snooze is a decision about this incident, which you make because you already know. Quiet hours are a standing rule about when you’re willing to be told, and they never silently drop the thing they delayed.

Use them for jobs where nobody is going to act at 3am anyway — a nightly report, a cache warm — and leave them off for anything where the answer is “wake me”.

Ping tokens

Each monitor has its own ping URL, and the token in it is the monitor’s identity:

https://ping.deadpost.dev/00000000-0000-7000-8000-000000000001

Anyone holding that token can check the monitor in. That is worth stating plainly, because the failure it enables is quiet: a leaked token doesn’t let an attacker read anything, it lets them mask a real outage by checking in on behalf of a job that isn’t running.

Treat it like a credential. It belongs in the environment or a secrets manager, not in a repository.

Rotation

Tokens can be rotated, and rotation has an overlap window: the new token becomes valid immediately while the old one keeps working until the window ends. Both check the monitor in.

The overlap is what makes rotation safe on a fleet. Deploying a new token to every box is not atomic — some machines pick it up in seconds, some on their next config push — and without an overlap the ones still holding the old token would silently stop checking in and start alerting. Rotate, roll the new value out, then let the window close.