Switching Uptime Monitoring Providers Without Losing Coverage

The riskiest moment in uptime monitoring isn't an outage - it's the week you switch providers. Cancel the old tool too early and you're flying blind; forget one cron job and your dead-man's switch is pinging a dead account. This is the vendor-neutral playbook for doing it without a coverage gap.

If you already know where you're coming from, here are the one-click paths into Vantaj:

• UptimeRobot → migrate in 60 seconds (docs)
• Pingdom → migrate in 60 seconds (docs)
• StatusCake → migrate in 60 seconds (docs)
• Better Stack → migrate in 60 seconds (docs)
• Anything else → bulk import from CSV (docs)

The rest of this post is the process around the import - because the import is the easy part.

Step 1: Inventory what you actually have

Before touching the new tool, list what the old one is doing. Not what you think it's doing - what it's configured to do:

• Every monitor, including the paused ones. Paused monitors are usually paused for a reason someone has forgotten; carry them over paused rather than deciding mid-migration.
• Every heartbeat, and - critically - every cron job, CI pipeline, and backup script that pings one. The monitors are in the dashboard; the pingers are scattered across crontabs and CI configs. Find them now, not after the cutover.
• Every alert channel and who's behind it: Slack channels, PagerDuty services, email lists, webhooks feeding other systems.
• Status pages and anything embedding them - custom domains, badges in READMEs, iframes in internal dashboards.

A spreadsheet is fine. The point is that step 4 has a checklist to verify against.

Step 2: Import into the new tool

With a one-click importer this is the sixty-second part: a read-only API key or token, a fetch, a review screen, an import. Monitor types, intervals, keyword assertions, and paused states translate automatically; the provider posts linked above document exactly what carries over from each source, and the honest list of what doesn't.

Coming from a tool without an importer, the CSV route gets you there with four columns.

Then do the one piece of setup no importer can do: alert channels. They don't transfer between providers - the integrations are structurally different - but in Vantaj you configure them once under Alerts & Notifications and they apply to every monitor, imported or not. Budget five minutes, not an afternoon.

Two things you should expect not to migrate, from any provider to any provider:

• Uptime history. No tool exposes it in an importable form. Your new graphs start at import time - which is exactly why the next step exists.
• Alert integrations, as above. Set up once, verify once.

Step 3: Run both in parallel (the step everyone skips)

Keep the old provider alive for a few days after the import. This is the cheapest insurance in the entire migration, and it's what makes the "do I lose history?" answer tolerable - there's no moment where nothing is watching.

During the parallel window, verify three things:

1. Both tools agree on reality. Same monitors up, same monitors down. Disagreements usually mean an import edge case - a wrong port, a keyword assertion inverted - and they're trivial to fix while you still have the old tool as a reference.
2. Alerts reach humans. Trip a test alert (pause a monitor's target, or use a deliberately-failing check) and confirm it lands in the right Slack channel or pager rotation from the new tool.
3. Heartbeats are checking in on their new URLs. This is gotcha number one, and it deserves its own section.

The heartbeat URL cutover

Imported heartbeat monitors get new ping URLs in the new tool. Nothing updates your cron jobs for you - until you edit them, they keep pinging the old provider, the old tool reports health, and the new tool reports silence.

The safe sequence: update every pinger from your step-1 inventory, then run both providers through at least one full cycle of your longest schedule. A daily backup heartbeat needs a day; a weekly report job needs a week. Only when every heartbeat has checked in on the new URL is the dead-man's-switch coverage actually transferred.

The status page cutover

Set up the new status page while both tools run, confirm it reflects the imported monitors, then move the URL your users know - repoint the custom domain, update the badge embeds - before the old page goes away. Done in this order, subscribers never see a dead page.

Step 4: Cut over alerts, then decommission

Once the parallel window has been quiet - or, better, has caught one real incident that both tools saw identically - flip the order of authority:

1. Silence the old tool's alerts (don't delete anything yet). The new tool is now the one that pages you.
2. Run one more alert cycle with the old tool muted. If nothing surprises you, the migration is functionally done.
3. Decommission: cancel the old subscription, revoke the API token you used for the import, and delete the old pingers' credentials from anywhere they lived. If the old tool has a free tier, keeping the account as a read-only archive of your historical uptime costs nothing.

Work through your step-1 inventory line by line - every monitor accounted for, every pinger updated, every channel firing, every embed repointed. That checklist is the difference between "we switched" and "we think we switched."

The short version

Inventory → import → parallel → cut over → decommission. The import takes a minute; the discipline around it takes a few days of mostly waiting. The two places migrations actually fail are the parallel window people skip and the heartbeat URLs people forget - give those two their due and the switch is boring, which is the goal.

Ready to run one? Create a free Vantaj account - 20 monitors free, no credit card - pick your import path above, and keep the old tool running until the new one has proven itself.