migrate-from-statuspageio

Migrating from Statuspageio (Atlassian Statuspage) to ilert

The object model lines up unusually well — component statuses map one for one, and so do incident statuses. That makes this migration feel like a copy job, which is the danger. What breaks is not the objects; it is who gets told, and when. The subscriber list does move — ilert has a dedicated import path that preserves existing consent — but only if you use it deliberately.

For ilert's own semantics and the CLI behaviour behind a bulk import, read the ilert-essentials skill alongside this one. Where Statuspage's own data lives — and how to hold a foreign API key while you read it — is under Reading the Statuspage side below; start there when the job is extraction rather than design.

Status and communication are two separate objects

In Statuspage, a component status change is itself a customer-facing event. It updates the page, fires webhooks and can notify component subscribers, with no incident involved.

ilert separates the two deliberately. A service's status describes what is currently true; a Status update is what you choose to say about it. Updating a service's status directly does not notify subscribers — they are notified when a status update is posted naming that service among its affected services. That split is what lets you correct a wrong status, move a service around during a noisy investigation, or let automation drive status continuously, without mailing your customer list every time the truth changes.

IMPORTANT: it does mean one thing has to change on the way in. Anything automated against the Statuspage API to flip component statuses now has to post a status update as well, not only set a status. A migration that transliterates "set component X to partial outage" gives you a page that is accurate and an audience that has not been told. Go through the automations one at a time and decide which of the two each one wanted — usually both, and an Incident Template makes the update side a single call.