[{"data":1,"prerenderedAt":358},["ShallowReactive",2],{"\u002Fblog\u002Fswitching-uptime-monitoring-providers":3},{"id":4,"title":5,"author":6,"body":8,"category":314,"date":315,"description":316,"extension":317,"faq":318,"howTo":334,"image":350,"lastUpdated":315,"meta":351,"navigation":352,"path":353,"readingTime":354,"seo":355,"stem":356,"__hash__":357},"blog\u002Fblog\u002Fswitching-uptime-monitoring-providers.md","Switching Uptime Monitoring Providers Without Losing Coverage",{"name":7},"Theo Cummings",{"type":9,"value":10,"toc":301},"minimark",[11,15,18,96,99,104,107,137,140,144,147,154,166,174,188,192,195,198,223,228,235,242,246,254,258,261,281,284,288,291],[12,13,14],"p",{},"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.",[12,16,17],{},"If you already know where you're coming from, here are the one-click paths into Vantaj:",[19,20,21,40,51,62,73,84],"ul",{},[22,23,24,28,29,34,35,39],"li",{},[25,26,27],"strong",{},"UptimeRobot"," → ",[30,31,33],"a",{"href":32},"\u002Fblog\u002Fmigrate-from-uptimerobot-in-60-seconds","migrate in 60 seconds"," (",[30,36,38],{"href":37},"\u002Fdocs\u002Fimport-uptimerobot","docs",")",[22,41,42,28,45,34,48,39],{},[25,43,44],{},"Pingdom",[30,46,33],{"href":47},"\u002Fblog\u002Fmigrate-from-pingdom-in-60-seconds",[30,49,38],{"href":50},"\u002Fdocs\u002Fimport-pingdom",[22,52,53,28,56,34,59,39],{},[25,54,55],{},"StatusCake",[30,57,33],{"href":58},"\u002Fblog\u002Fmigrate-from-statuscake-in-60-seconds",[30,60,38],{"href":61},"\u002Fdocs\u002Fimport-statuscake",[22,63,64,28,67,34,70,39],{},[25,65,66],{},"Better Stack",[30,68,33],{"href":69},"\u002Fblog\u002Fmigrate-from-better-stack-in-60-seconds",[30,71,38],{"href":72},"\u002Fdocs\u002Fimport-betterstack",[22,74,75,28,78,34,81,39],{},[25,76,77],{},"Uptime Kuma",[30,79,33],{"href":80},"\u002Fblog\u002Fmigrate-from-uptime-kuma-in-60-seconds",[30,82,38],{"href":83},"\u002Fdocs\u002Fimport-uptime-kuma",[22,85,86,28,89,34,93,39],{},[25,87,88],{},"Anything else",[30,90,92],{"href":91},"\u002Fblog\u002Fbulk-import-monitors-csv","bulk import from CSV",[30,94,38],{"href":95},"\u002Fdocs\u002Fimport-csv",[12,97,98],{},"The rest of this post is the process around the import - because the import is the easy part.",[100,101,103],"h2",{"id":102},"step-1-inventory-what-you-actually-have","Step 1: Inventory what you actually have",[12,105,106],{},"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:",[19,108,109,115,125,131],{},[22,110,111,114],{},[25,112,113],{},"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.",[22,116,117,120,121,124],{},[25,118,119],{},"Every heartbeat",", and - critically - ",[25,122,123],{},"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.",[22,126,127,130],{},[25,128,129],{},"Every alert channel"," and who's behind it: Slack channels, PagerDuty services, email lists, webhooks feeding other systems.",[22,132,133,136],{},[25,134,135],{},"Status pages"," and anything embedding them - custom domains, badges in READMEs, iframes in internal dashboards.",[12,138,139],{},"A spreadsheet is fine. The point is that step 4 has a checklist to verify against.",[100,141,143],{"id":142},"step-2-import-into-the-new-tool","Step 2: Import into the new tool",[12,145,146],{},"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.",[12,148,149,150,153],{},"Coming from a tool without an importer, the ",[30,151,152],{"href":91},"CSV route"," gets you there with four columns.",[12,155,156,157,160,161,165],{},"Then do the one piece of setup no importer can do: ",[25,158,159],{},"alert channels",". They don't transfer between providers - the integrations are structurally different - but in Vantaj you configure them once under ",[30,162,164],{"href":163},"\u002Fdocs\u002Falerts","Alerts & Notifications"," and they apply to every monitor, imported or not. Budget five minutes, not an afternoon.",[12,167,168,169,173],{},"Two things you should expect ",[170,171,172],"em",{},"not"," to migrate, from any provider to any provider:",[19,175,176,182],{},[22,177,178,181],{},[25,179,180],{},"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.",[22,183,184,187],{},[25,185,186],{},"Alert integrations",", as above. Set up once, verify once.",[100,189,191],{"id":190},"step-3-run-both-in-parallel-the-step-everyone-skips","Step 3: Run both in parallel (the step everyone skips)",[12,193,194],{},"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.",[12,196,197],{},"During the parallel window, verify three things:",[199,200,201,207,217],"ol",{},[22,202,203,206],{},[25,204,205],{},"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.",[22,208,209,212,213,216],{},[25,210,211],{},"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 ",[170,214,215],{},"new"," tool.",[22,218,219,222],{},[25,220,221],{},"Heartbeats are checking in on their new URLs."," This is gotcha number one, and it deserves its own section.",[224,225,227],"h3",{"id":226},"the-heartbeat-url-cutover","The heartbeat URL cutover",[12,229,230,231,234],{},"Imported heartbeat monitors get ",[25,232,233],{},"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.",[12,236,237,238,241],{},"The safe sequence: update every pinger from your step-1 inventory, then run both providers through ",[25,239,240],{},"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.",[224,243,245],{"id":244},"the-status-page-cutover","The status page cutover",[12,247,248,249,253],{},"Set up the new ",[30,250,252],{"href":251},"\u002Fdocs\u002Fstatus-pages","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.",[100,255,257],{"id":256},"step-4-cut-over-alerts-then-decommission","Step 4: Cut over alerts, then decommission",[12,259,260],{},"Once the parallel window has been quiet - or, better, has caught one real incident that both tools saw identically - flip the order of authority:",[199,262,263,269,275],{},[22,264,265,268],{},[25,266,267],{},"Silence the old tool's alerts"," (don't delete anything yet). The new tool is now the one that pages you.",[22,270,271,274],{},[25,272,273],{},"Run one more alert cycle"," with the old tool muted. If nothing surprises you, the migration is functionally done.",[22,276,277,280],{},[25,278,279],{},"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.",[12,282,283],{},"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.\"",[100,285,287],{"id":286},"the-short-version","The short version",[12,289,290],{},"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.",[12,292,293,294,300],{},"Ready to run one? ",[30,295,299],{"href":296,"rel":297},"https:\u002F\u002Fapp.vantaj.co\u002Fregister",[298],"nofollow","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.",{"title":302,"searchDepth":303,"depth":303,"links":304},"",2,[305,306,307,312,313],{"id":102,"depth":303,"text":103},{"id":142,"depth":303,"text":143},{"id":190,"depth":303,"text":191,"children":308},[309,311],{"id":226,"depth":310,"text":227},3,{"id":244,"depth":310,"text":245},{"id":256,"depth":303,"text":257},{"id":286,"depth":303,"text":287},"tutorials","2026-07-05","A vendor-neutral playbook for migrating uptime monitoring safely: inventory, import, run in parallel, cut over alerts, decommission - plus one-click migration paths from UptimeRobot, Pingdom, StatusCake, Better Stack, and CSV.","md",[319,322,325,328,331],{"q":320,"a":321},"How long does a monitoring migration actually take?","The import itself takes about a minute with a one-click importer or a CSV. The full migration - including a parallel-running window and alert cutover - is realistically two to five days, most of which is waiting to confirm the new tool behaves before you cancel the old one.",{"q":323,"a":324},"Do I lose my uptime history when I switch?","Yes. No provider exposes history in a form another tool can import, so your history in the new tool starts at import time. If unbroken records matter, keep the old account alive as a read-only archive and run both in parallel through the transition.",{"q":326,"a":327},"Will my status page break during the migration?","Not if you sequence it: set up the new status page first, confirm it reflects the imported monitors, then update the URL your users know - or point your custom domain at the new page - before shutting the old one down.",{"q":329,"a":330},"Do alert integrations transfer between providers?","No - notification channels work too differently across tools to map automatically. The good news: in Vantaj you set up channels once (Slack, PagerDuty, Telegram, webhooks, email) and they apply to every monitor, so this is a five-minute job, not a per-monitor one.",{"q":332,"a":333},"What's the biggest thing that goes wrong in monitoring migrations?","Heartbeat URLs. Imported heartbeat monitors get new ping URLs, but your cron jobs keep pinging the old provider until you update them - so the new tool sees silence and the old tool sees health. Update every job and run both in parallel for at least one full schedule cycle.",{"name":335,"description":336,"steps":337},"How to switch uptime monitoring providers without losing coverage","Migrate your monitors to a new provider safely by inventorying, importing, running both tools in parallel, and cutting over alerts deliberately.",[338,341,344,347],{"name":339,"text":340},"Inventory what you have","List every monitor, heartbeat, alert channel, and status page in the old tool - including the paused ones and the cron jobs pinging heartbeat URLs.",{"name":342,"text":343},"Import into the new tool","Use a one-click importer (UptimeRobot, Pingdom, StatusCake, Better Stack) or a CSV upload to recreate your monitors in Vantaj, then set up alert channels once.",{"name":345,"text":346},"Run both providers in parallel","Keep the old tool alive for a few days. Confirm the new tool sees the same reality - same up\u002Fdown states, alerts firing to the right channels, heartbeats checking in on their new URLs.",{"name":348,"text":349},"Cut over and decommission","Point status pages and dashboards at the new tool, silence the old tool's alerts, and cancel it once you've gone a full alert cycle without surprises.",null,{},true,"\u002Fblog\u002Fswitching-uptime-monitoring-providers",7,{"title":5,"description":316},"blog\u002Fswitching-uptime-monitoring-providers","MUbR4rhCXYTfVRb28WzGY_1gZAr0I7BD1apJVcCAM90",1783289819469]