How to Migrate From IsDown Without a Gap in Alert Coverage

To migrate from IsDown safely: list every monitor and alert destination you have, confirm the new tool covers each vendor and component, rebuild the alerts, then run both tools side by side until you have seen at least one real vendor incident arrive in both. Only then move or retire your status pages, cancel IsDown, and update your vendor records.

The whole move takes an afternoon of work spread over two to four weeks of waiting, and the waiting is the part that protects you. A monitoring tool that is silent looks exactly like a monitoring tool that is working, until the outage it misses.

This checklist is for teams leaving IsDown for any tool, not only ours. Where a step depends on the destination, we say what to check, and where PulsAPI behaves differently from IsDown we say so, because those differences are what a parallel run is for. If you are still choosing a tool, start with IsDown alternatives.

Before you touch the new tool, make an inventory. For each IsDown board, record every monitored vendor, the components or regions you selected for it, and every notification destination: Slack and Teams channels, email lists, PagerDuty or Opsgenie services, webhooks, and anything wired through Datadog, Zendesk or another integration.

Then record what is not a monitor: status pages and their subscriber counts, private Zendesk or Microsoft 365 tenant status, SSL certificate checks, API or MCP clients that read IsDown data, and any alert filters you set up so a minor incident does not page anyone. These are the items that are easiest to forget and hardest to notice once they are gone.

A spreadsheet with one row per vendor and one column per destination is enough. You will use it again in step 6 to confirm nothing went missing.

Search for every vendor on your list in the new tool, and then check the components, not just the name. Two tools can both list AWS while only one lets you watch a single service in a single region. If your IsDown monitor followed one component, make sure you can follow that component again.

Expect a few misses, especially if you are moving to a smaller catalog. Most tools take vendor requests; in PulsAPI the onboarding search shows a request form when a vendor is not found, and requests are reviewed by hand. Decide before you switch what you will do about a missing vendor: wait, keep IsDown for it, or accept the gap. The service directory lists everything PulsAPI tracks today.

Recreate each destination from your inventory and check which plan unlocks it. Entry plans across this category tend to cover email and one or two chat tools, while PagerDuty, Opsgenie and Datadog sit on higher tiers. In PulsAPI, email is on every plan, Slack, Discord, Microsoft Teams and Google Chat are on Pro, and PagerDuty and Opsgenie are on Business.

Send a test alert to every destination before you rely on it. PulsAPI's onboarding has a test step that sends a labelled test alert and shows how a past incident for one of your vendors would have looked, which is a quick way to check formatting without waiting for an outage. If you are rebuilding a long list, a GitHub stack scan can propose vendors from your repositories instead of you retyping them.

Keep IsDown running. Leave both tools alerting into the same channels, or into a shared test channel, for at least two weeks, and do not cancel until at least one real incident from a vendor you watch has arrived through both. With 40 vendors, that usually takes days, not weeks: in our Q3 2026 outage report, 176 vendors published 3,271 incidents in one quarter, about 1.4 per vendor per week.

When it happens, compare three things: did both tools alert, did both name the same component, and how far apart were the alerts. Differences in timing are expected and worth understanding rather than treating as a failure. Some tools alert on the first change they see. PulsAPI deliberately waits until a status change has held for 5 minutes, so a vendor that flaps between degraded and operational sends one alert instead of ten. In a parallel run it will often be a few minutes behind a tool that does not wait.

Status pages are the part of IsDown that does not move by itself. Subscriber lists are personal data your subscribers gave to IsDown for that page, so plan to ask them to subscribe again on the new page rather than exporting and re-importing addresses without their consent.

If the destination does not host status pages at all, which is the case for PulsAPI, you have two clean choices: keep a small IsDown plan just for the pages, or move them to a dedicated status page product. Make that choice before step 7, not after, so subscribers never hit a dead page.

Once the parallel run has passed, switch IsDown's alerts off at the destination end first: remove its Slack app, PagerDuty service or webhook, rather than deleting the IsDown account. That way you can turn it back on in minutes if something is wrong.

Then go back to the spreadsheet from step 1 and tick every row. Every vendor, component and destination should now exist in the new tool, or carry a written decision that it was dropped on purpose. Pay special attention to API and MCP clients, dashboards on office TVs and scripts that called IsDown's API, since none of them will complain when they stop receiving data.

Check your renewal date before you start, not at the end. IsDown's pricing page says refunds apply if you cancel within 10 days of subscribing, so do not count on a refund once a renewal has gone through. If you are on an annual plan with months left, you can take the parallel run slowly. If renewal is close, start sooner.

Export anything you want to keep before the account closes: your own alert log, acknowledgements, notes and any reports you built for an SLA review. That data does not transfer between tools. Vendor incident history is different, because aggregators keep their own records of what each vendor published; PulsAPI shows a vendor's past incidents as soon as you add it, within your plan's window of 15 days on Free, 90 days on Pro and 13 months on Business.

Finally, update your records, whether you leave or stay. Since 1 June 2026 the company behind IsDown is UptimeRobot s.r.o. in the Slovak Republic, not While True Ventures, Lda in Portugal. If your vendor register, records of processing or DPA name the old company, correct them. If you are leaving, record the end date and confirm deletion of your account data under the new company's terms.

For the tool you are moving to, add it to the same register before it receives any personal data, such as your team's email addresses. Ask for its terms, privacy policy, data processing agreement and list of subprocessors. That takes ten minutes and saves a security review from stopping the migration halfway.

How long does it take to migrate from IsDown? The hands-on work is a few hours for a typical stack. Plan two to four weeks overall, because you should run both tools in parallel until at least one real vendor incident has arrived through both before you cancel IsDown.

Can I import my IsDown monitors into another tool? Not directly; none of the common alternatives import IsDown configurations. Rebuild from an inventory of vendors, components and destinations. PulsAPI can propose vendors by scanning your GitHub repositories, which shortens the rebuild.

Will I lose my IsDown incident history? Your own alert history and notes stay in IsDown, so export what you need before you cancel. Vendor incident history usually is not lost: aggregators keep their own record of what vendors published, and PulsAPI shows it within your plan's history window.

Do I have to migrate because UptimeRobot bought IsDown? No. IsDown says plans, prices, logins and data are unchanged, and UptimeRobot says IsDown stays a standalone product. The only action every customer should take is updating vendor records to name UptimeRobot s.r.o.