Importing and exporting monitors

If you already have jobs being monitored somewhere else — or just a crontab full of jobs that aren’t — you don’t have to recreate them by hand.

Sources

Source	What you provide
Crontab	Paste the contents of a crontab. Each schedule line becomes a monitor.
Healthchecks.io	A read-only API key. Your existing checks are mirrored.
Cronitor	A read-only API key. Your existing monitors are mirrored.
deadpost	A JSON file from Export. Restore a backup, or copy monitors into another workspace.

For the two hosted sources, a read-only key is enough and is what you should use. Importing only ever reads from them — nothing is created, changed or deleted on the other side, and giving it a read-only key means it can’t be.

Preview, then confirm

Every import runs in two phases, and the first one writes nothing.

Preview shows exactly what would be created: one row per detected job, with the name and schedule deadpost worked out. Nothing exists yet.

Confirm creates them. You choose which rows to bring across — the default is all of them — and you can rename any row before it’s created.

The two-phase shape exists because a bulk import is hard to undo. A crontab with forty lines in it will produce some rows you want and some you don’t (the @reboot housekeeping, the commented-out experiment), and finding that out after sixty monitors exist is worse than finding it out in a list.

Tip

Names are the thing worth spending the preview on. An imported monitor named 0 3 * * * /usr/local/bin/backup.sh is accurate and useless in an alert at 3am. Rename it to nightly-backup while it’s still a preview row.

What comes across

Schedules import faithfully. A cron expression stays a cron expression rather than being flattened into “roughly every N hours” — so a job that runs 0 9,18 * * 1-5 keeps firing twice on weekdays and stays quiet at the weekend, instead of alerting all through Saturday.

Everything else — grace windows, routing, quiet hours — uses your workspace defaults, because those are decisions about how you want to be alerted rather than facts about the job. Adjust them after the import.

Coming from Healthchecks.io or Cronitor

The model is close enough that most of what you know transfers directly. The vocabulary differs:

You know it as	Here it’s called	Notes
Check (Healthchecks.io) / Monitor (Cronitor)	Monitor	Same thing: one scheduled job being watched.
Period / Schedule	Period or cron schedule	Both are first-class — see Concepts.
Grace	Grace	Identical meaning.
Ping URL	Ping URL	Same idea; ours carries a UUID token.
Integration	Channel + route	A configured destination, and a rule about what reaches it — see Integrations.
Project / Tag	Environment	Scoping for routing, not just labelling.

Three things behave differently enough to be worth knowing on day one:

• Cron schedules stay cron schedules. A job that runs 0 9,18 * * 1-5 is imported as that expression in its timezone, not flattened into “roughly every N hours” — so it stays quiet at the weekend instead of alerting from Friday evening.
• Routing is a union across three scopes, not a single per-monitor setting. A monitor’s alerts go to its own routes plus its environment’s plus the workspace-wide ones. That trips people up coming from a per-check integration list — see Routing is additive.
• Pause and snooze are separate. Pausing stops evaluation; snoozing suppresses alerts while evaluation continues. If you’ve been pausing checks to quiet an incident, snooze is the one you actually wanted.

Tip

Your old monitoring keeps running during a migration — nothing here touches it. Run both for a cycle or two, confirm the same jobs report healthy in both, then turn the old one off.

After importing

Imported monitors start in pending: they exist, and they’re waiting for a first check-in. They will not alert until they’ve seen one, so an import can’t page you for forty jobs at once.

That leaves one step, and it’s the one people forget: the jobs themselves still have to check in. Importing brings the monitor definitions across, not your crontab’s ping URLs. Each imported monitor has its own new token, and the job needs to call it — see the Quickstart for the one-line version, or the CLI if you’d rather wrap the command than edit it.

Exporting

Everything above runs in reverse. Monitors → Export downloads every monitor in the workspace as a file, in one of two formats.

Format	What it is
JSON	Every setting, in the same field names the importer reads — and importable straight back (see Exports import back). The one to keep as a backup or feed to a script.
Crontab	A commented crontab: one schedule line per monitor with its heartbeat curl. Written to be read and merged into your own crontab.

Export is a read, so anyone in the workspace can do it, including viewers. Leaving is not a permission.

It always exports everything. The filters on the monitor list don’t apply — a backup that quietly contains 12 of your 40 monitors because a filter chip was still selected is a bad thing to discover during a migration.

Ping tokens are excluded by default

A monitor’s ping token is a write credential: a plain GET on its URL marks the job healthy, and /fail fires a real alert to whoever is on the receiving end. Export files get committed, dropped in shared drives and pasted into tickets, so they don’t carry tokens unless you tick Include ping tokens.

Tick it when you’re rebuilding the jobs themselves and need working URLs. Leave it off for a backup, an audit, or anything you’re sending to somebody else. The crontab format writes YOUR-PING-TOKEN in place of each excluded token so it’s obvious what’s missing.

Badge tokens are always included. They’re public and read-only by construction — they resolve to status, uptime and the timeline and nothing else — so a README badge survives the round trip.

Exports import back

The JSON export is a deadpost import source, so the round trip is closed: export a workspace, import the file, get your monitors back. Use it to restore a backup, or to copy a set of monitors into a second workspace.

Re-importing a workspace’s own backup into that same workspace creates nothing. Every entry keeps the provenance it was exported with, so it matches the monitor it came from and shows up in the preview as already imported — the same top-up behaviour the hosted sources have. That is what makes a backup safe to import when you’re not sure whether you need it.

Two things don’t survive, both deliberately:

• Ping tokens. A restored monitor gets a fresh one, even if the file contains tokens. A token is minted server-side; accepting one from a file would let anyone who can write JSON pick a credential. Your jobs need the new URLs.
• Live state — current status, last check-in, pause and snooze windows. An export carries the configuration you chose, not the moment it was taken. A restored monitor starts in pending and waits for its first check-in.

Everything else comes across: schedules, grace, tags, environments (matched by name), quiet hours, escalation, alert thresholds.

What the crontab export is (and isn’t)

Every line in it is commented out, on purpose.

A cron line whose only command is curl <ping url> reports the job healthy on schedule whether or not the job ran — a monitor that can never fail, which is the exact failure this product exists to catch. So the file is a reference to merge into a crontab, not a crontab to install: pasting the whole thing into crontab -e deliberately does nothing. Append the curl to the end of your real command instead:

0 3 * * * /opt/backup.sh && curl -fsS https://ping.deadpost.dev/<token>

Two things it flags rather than hiding:

• Interval monitors have no cron expression of their own. The line shown is the closest crontab cadence to the configured period, marked (approx) when the two don’t line up exactly — a 7-minute period has no crontab spelling (*/7 skips from :56 to the next hour).
• Cron monitors keep their timezone, crontab lines can’t. A non-UTC monitor says so in its comment, because a line pasted onto a UTC box fires at the wrong hour and nothing warns you.