What’s new

We import monitors from crontabs, Healthchecks.io and Cronitor. Until now there was no way back out, which made “no lock-in” a nice thing to say rather than a thing you could do.

Monitors → Export downloads the whole workspace in one of two formats:

• JSON — every setting, in the same field names the importer reads. Keep it as a backup, diff it in git, feed it to a script.
• Crontab — one commented schedule line per monitor with its heartbeat curl, written to be read and merged into your own crontab.

The JSON imports straight back. It’s a fourth import source, so the round trip is closed: export a workspace, import the file, get your monitors back — into the same workspace as a restore, or into another one as a copy. Re-importing your own backup into the workspace it came from creates nothing; every entry keeps the provenance it was exported with, so it matches the monitor it came from and the preview marks it already imported. A backup you’re unsure about is safe to try.

Restored monitors get fresh ping tokens — a token is minted here, never accepted from a file — so your jobs need the new URLs.

Two more decisions worth knowing about.

Ping tokens are excluded by default. A ping token is a write credential — a plain GET on its URL marks the job healthy, and /fail fires a real alert — and export files end up in shared drives and git repos. There’s a checkbox when you genuinely need working URLs. Badge tokens always come along; they’re public and read-only by construction, so a README badge survives the trip.

Every line of the crontab export is commented out. A cron line whose only command is curl <ping url> reports the job healthy whether or not the job ran — a monitor that can never fail, which is the one thing we’re here to catch. Append the curl to your real command instead; the file shows you how.

Export is a read, so anyone in the workspace can do it, viewers included.

A ping tells you a job checked in. It doesn’t tell you what the job did.

Monitor detail pages now carry a Runs tab: one row per run, with when it started, when it finished, how long it took, and how it ended. Runs recorded through the SDKs carry more — the exit code, and the tail of anything the job wrote to stderr, expandable in place.

Three states are worth calling out, because they mean different things:

• ok — the job started and finished.
• failed — the job finished and told us it failed, with an exit code.
• abandoned — the job started and never came back. Nothing reported a failure; the run simply stopped existing, which is the case a plain success-ping monitor cannot see at all.

Nothing to switch on. Bare curl pings produce the rows they can; SDK-driven jobs produce the full picture.

Two reports now arrive on their own schedule:

• The weekly digest, Monday mornings. Which monitors lost time, how that compares with the week before, and which ones had a clean week. Downtime is measured against the time a monitor was actually being watched, so a paused job never reports a flawless week it spent switched off.
• The monthly usage summary, on the 1st. Monitors and seats against your plan’s ceilings, alert volume, and any plan changes. It is not an invoice — Paddle is the merchant of record and sends the receipt.

Both are withheld entirely when there is nothing to say. An account with no monitors gets silence rather than a report full of zeroes.

Your inbox is yours

Email opt-ins moved off the workspace and onto the person. They used to be a workspace setting, which meant one teammate’s opt-out silenced the other and one teammate’s opt-in subscribed them. Each person now controls their own, under Settings → Notifications, and every bulk email carries a working one-click unsubscribe.

Monitor alerts are unaffected. They go to your configured channels and are always delivered.

Put your status where people already look

Public status pages picked up two embeddable surfaces:

• an SVG badge for a README — the same shape as a CI badge, cached at the edge;
• an embeddable card you can iframe into your own docs, dashboard or intranet page.

Both use a separate read-only token, not your ping URL. Rotating a monitor’s ping credential does not break a badge you added to a README a year ago, and a badge URL can never be used to mark a job healthy.

A job that finishes late is still a problem

Silence is the obvious failure. The quieter one is the nightly job that used to take four minutes and now takes fifty — it still checks in, so nothing is technically down, and nothing tells you until it collides with the next morning.

Deadpost now learns each monitor’s normal run duration and alerts when a run lands far outside it. It’s judged against that monitor’s own recent history, so a job that has always been slow doesn’t page you for being itself.

curl is a fine way to say “I’m alive”. It is a poor way to say “I started, I ran for six minutes, I exited 1, and here is what I printed.”

Three SDKs — Go, Python and Node — and a single static deadpost binary now wrap the job itself:

deadpost run --token $TOKEN -- ./nightly-export.sh

They report the start and the finish, the exit code, and the tail of the output. If the network blips they retry; if it is properly down they spool the report to disk and send it on the next run, so an outage on our side doesn’t turn into a false alarm on yours. The Python and Node packages have zero runtime dependencies, and the CLI is a single static binary with none at all.

Every port implements one written specification and runs the same shared test corpus, so run means the same thing in every language.

A documentation site launched alongside them, with the install steps, the run lifecycle, and worked examples for each language.