Migrating from Statuspage

You need two things from Statuspage and one decision from yourself.

• Your page ID — the id segment in your management URL: manage.statuspage.io/pages/<this part>.
• An API key — Statuspage → Account Settings → API Keys. IsItStillUp uses it once, for this import, and never stores it. It is held encrypted for the few minutes between the preview and your confirmation, then destroyed.
• A target page in IsItStillUp — importing into an existing page merges into it rather than replacing it, so a fresh empty page is the simplest thing to aim at the first time.

A note on that key: Statuspage has no read-only API keys, so the one you generate can write as well as read. IsItStillUp only ever issues GET requests against it — the importer has no code path that writes to Statuspage — but it is still worth revoking the key once you’ve finished migrating.

Then open Import from Statuspage in your dashboard. The first step is read-only: it fetches everything, shows you counts for each kind of thing, and writes nothing until you press the button.

Everything below is what the importer actually does, item by item. “Partly” means it comes across with a caveat worth reading rather than a footnote you can skip.

Incident history is capped at the 500 most recent incidents and subscribers at 5,000 per channel. If your page is bigger than that, the preview says so before you commit — get in touch and we’ll run the rest.

Three of the gaps above are worth more than a table row, because each has a workaround that’s better than nothing.

Metric history. Statuspage has no API for reading historical metric data points, so metric history starts fresh in IsItStillUp — the definitions come across, the charts begin collecting on cutover. This is a limit of Statuspage’s API, not of IsItStillUp: it offers endpoints to push data points and to delete them, but none that reads them back. The practical answer is to point whatever was feeding Statuspage — your own collector, or a Datadog / New Relic integration — at IsItStillUp instead. That system still has the history; Statuspage was only ever displaying it.

Page followers on private pages. Statuspage’s page access users are accounts on Statuspage, with logins IsItStillUp has no way to accept. IsItStillUp’s equivalent is an audience: a named group with its own access link, optionally password-protected, that sees a chosen subset of components. Recreate your audiences under Audiences and send out the new links during the overlap week described below — that way nobody is locked out at any point.

Uptime history. Statuspage will only report uptime as a percentage over a window, and only for components with its uptime showcase turned on. There is no per-event history to import. IsItStillUp derives uptime from its own monitors, so set those up early — every day they run before cutover is a day of real history on your new page.

The import itself is the short part. Here is the whole sequence, with rough timings, assuming you already have an IsItStillUp account.

1. Create the page (1 min). Name it and pick a slug. Leave the branding alone — the import fills it in.
2. Preview the import (2 min). Paste your Statuspage page ID and API key. Read the counts against what you know is on the old page. Nothing has been written yet.
3. Run it (1–3 min). Leave “Also import look & feel” ticked unless you’re redesigning at the same time — one change at a time is easier to debug.
4. Spot-check (5 min). Open the public page. Check the newest three incidents, the component tree, and your subscriber counts by channel.
5. Set up your domain (3 min). Add your status hostname under Settings → Domain and create the CNAME it gives you. Do not remove the Statuspage record yet — see the overlap section.
6. Point your monitors and integrations at IsItStillUp (5 min). Create an API key under Settings → API keys and swap the base URL in whatever opens incidents automatically.

That is a working status page with your full history on it. Everything after this point is about retiring the old one safely.

Don’t cut over in one step, and don’t cancel Statuspage the same day. Run both for about a week, with a clear rule about which is authoritative:

• Days 1–7: IsItStillUp is where you post, Statuspage is read-only. Every new incident and maintenance goes into IsItStillUp. Nobody posts to Statuspage. The old page stays up, unchanged, as a fallback and as a reference.
• Move DNS when you’ve had a real incident. The confidence you want isn’t “the import looked right”, it’s “we ran an incident through this and the notifications arrived”. If a quiet week gives you no incident, post a short scheduled maintenance and watch it land.
• Lower your DNS TTL first. Drop the record’s TTL to 300 seconds a day before you switch it, so a rollback takes five minutes instead of an afternoon. Raise it again once you’re settled.
• Re-run the import right before you close the account. It fills gaps rather than duplicating, so anything that happened on Statuspage during the overlap gets picked up.

The subscribers are why this ordering matters. They came across already verified, so they start receiving IsItStillUp’s notifications from the moment you post here — which means during the overlap they are already being served by the new page, before the URL they bookmarked has moved. That’s the property that makes the switch invisible to them.

The reason most Statuspage migrations stall isn’t the data — it’s the pile of scripts, bots and runbooks that call the API. IsItStillUp’s REST API covers the same operations with the same vocabulary: components with a status you flip, incidents you open with a body and a list of affected components, updates you append, maintenance you schedule. In most cases the change is a base URL and a key, not a rewrite.

# Before (Statuspage)
curl -sS "https://api.statuspage.io/v1/pages/$PAGE/incidents" \
  -H "Authorization: OAuth $STATUSPAGE_KEY" \
  -d "incident[name]=Elevated error rates" \
  -d "incident[status]=investigating"

# After (IsItStillUp)
curl -sS "$BEACON_URL/api/v1/pages/$PAGE_ID/incidents" \
  -H "Authorization: Bearer $BEACON_API_KEY" -H "Content-Type: application/json" \
  -d '{"title":"Elevated error rates","status":"investigating","body":"We are investigating."}'

Two differences to know about. IsItStillUp takes JSON bodies and a bearer token rather than form-encoded fields and OAuth. And an incident here always opens with an update body, because a status page entry with no text on it helps nobody.

Beyond that: the same key drives an MCP server if you’d rather an agent operated your status page, and incident webhooks are signed so you can verify them. Both are covered in the API reference. Watching a third-party MCP server as one of your dependencies? See MCP status.

The importer is safe to run more than once against the same page. It doesn’t duplicate what it already brought across, and each re-run is an upgrade rather than a copy:

• Components and templates are matched by name, so existing ones are reused, not cloned.
• Incidents are matched on title plus start time. An incident that’s already here is skipped — except that a postmortem written on Statuspage since your last run gets filled in.
• Subscribers are matched on their address or number, so only genuinely new people are added.
• Branding is merged, so anything you’ve customized in IsItStillUp since survives a re-run.

This is what makes the overlap week practical: import early, keep working, and re-run just before you close the Statuspage account to sweep up everything that happened in between.

Stuck on something this page doesn’t cover? The import preview reports every case it had to make a judgement call on, and those warnings are the fastest thing to send us.