Importing 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.

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.