Migrate from Statuspage
Move services, components, incidents, and subscribers from Atlassian Statuspage to Observer.
This guide covers a structured migration from Atlassian Statuspage to Observer. The two products share a customer-facing surface, but their backing models differ: Statuspage records component state manually or through an API call; Observer derives status from metrics that an agent collects in your network. Plan the migration around that difference.
Model differences to plan for
| Statuspage concept | Observer equivalent | Notes |
|---|---|---|
| Component | Metric (one or more, behind a service) | A Statuspage component represents the operator's manual verdict. An Observer metric represents a measured value evaluated against thresholds. One Statuspage component often becomes one Observer service with two or three Observer metrics. |
| Component group | Service | Logical grouping. Maps cleanly. |
| Manual incident state | Update with Incident type | Same semantics: posted updates with timeline. |
| Status indicator (operational, degraded, partial outage, major outage) | Rolled-up page status (healthy, degraded, unhealthy) | Page rollup uses unhealthy=3 > degraded=2 > healthy=1. Pick the worst child status. |
| API-driven component update | Metric reported by the agent | Stop calling Statuspage's PATCH /components/:id. The agent's status push replaces it. |
| Subscribers (email / SMS / Slack / webhook) | Page subscribers + outbound webhooks | Email subscribers move with the data export. SMS is not supported; Slack and PagerDuty are reachable through outbound webhook subscriptions. |
| Public status page domain | Status page subdomain | Both products serve a customer-facing domain. Plan a DNS cutover window. |
| Maintenance windows | Update with Scheduled maintenance type | Posted in advance, displays on the page during the window. |
Steps
Inventory the Statuspage account
Pull the list of:
- Components and component groups (one row per metric to define in Observer).
- Past 90 days of incidents (for the changelog you publish on the Observer page).
- Active subscribers, exported as CSV.
- Webhook subscribers, with their endpoint URLs.
Statuspage's REST API exposes each of these. The export from Account > Audit log captures incident history; the Subscribers page exports CSV directly.
Stand up the Observer side in parallel
Follow Define your first metric to install an agent and define a first reporting metric. Build out the remaining metrics, services, and SLOs without touching the Statuspage account. The two systems run side-by-side until the DNS cutover.
For each Statuspage component, decide on the source signal:
- A latency or error-rate query already in Prometheus (use the Prometheus probe).
- An HTTP endpoint that returns 200 when the component is healthy (use the HTTP probe).
- A TCP socket, DNS record, or TLS certificate (matching probe type).
If a Statuspage component has no measurable signal today, that is a signal of toil debt: the component's "operational" state was the operator's manual verdict. Pick the closest measurable proxy and document the gap.
Build the status page
Open Pages > New page in the Observer console. Recreate the public-facing layout: title, theme, services, metrics, SLO strip. The page is reachable on
<subdomain>.<your-cloud-host>immediately, before the DNS cutover.If the Statuspage account uses customer-scoped views (visible under different domains per customer), see Configure customer-scoped pages.
Backfill incidents
Observer renders updates posted on the page. To preserve the public changelog, post each historical Statuspage incident as an Update with type
Incident, dated to its originalcreated_at. The console's Updates > New update form accepts a custom timestamp.For high-incident accounts, scripting this against the Statuspage incident export and the Observer API is the practical path; for a typical SMB account with under 50 incidents a year, manual entry is fast.
Migrate subscribers
Observer accepts an email-subscriber import via the API. For webhook subscribers, recreate the subscription in Webhooks > New subscription, point it at the same endpoint URL, and pick the events that match what the consumer expects. Webhook payload shapes are documented in Webhook payload reference.
SMS subscribers need to be re-acquired. Email those subscribers during the migration window with a link to the Observer subscribe form on the new page.
Cut over DNS
When the Observer page renders correctly and all subscribers are migrated, point your status subdomain (commonly
status.<domain>) at the Observer cloud's wildcard. The page resolves immediately; visitors see no transition.Disable updates from the Statuspage API in your alerting and CI systems; the agent's metric pushes now drive Observer's status verdict. Cancel the Statuspage subscription after one billing cycle of overlap to allow rollback if the migration surfaces any gap.
API parity matrix
For teams wiring CI / IR automation, this table maps the Statuspage endpoint to its Observer equivalent. See Create incidents via API for end-to-end examples.
| Statuspage | Observer | Notes |
|---|---|---|
GET /pages/{id}/incidents | GET /api/v1/incidents | Same cursor-paged list shape; Observer adds state and since filters. |
POST /pages/{id}/incidents | POST /api/v1/incidents | Observer adds affected_services, visible_to_customer_ids, publish flag, initial_message. |
PATCH /pages/{id}/incidents/{id} | PATCH /api/v1/incidents/{id} + POST /publish | Statuspage rolls publish + edit into one call; Observer separates them so drafts are explicit. |
POST /pages/{id}/incidents/{id}/components (set state on component) | Wired automatically when incident lists affected_services containing manual metrics; see Manual metrics. | |
| (no equivalent) | POST /api/v1/incidents/from-metric/{metricId} | Pre-fill a draft from a flipped metric. Observer-only. |
POST /pages/{id}/incidents/{id}/messages | POST /api/v1/incidents/{id}/messages | Same shape; Observer's Resolved message also flips the parent state. |
DELETE /pages/{id}/incidents/{id} | DELETE /api/v1/incidents/{id} | Observer is soft-delete (deleted_at); Statuspage is hard-delete. |
POST /pages/{id}/incidents/{id}/scheduled-maintenances | POST /api/v1/maintenances | Observer auto-transitions scheduled → in_progress → completed on the configured times via cron; Statuspage requires manual start/complete. |
GET /pages/{id}/page-access-users | (none) | Observer's customer-scoped access uses JWT claims; no per-customer API for the user list. |
POST /pages/{id}/subscribers | POST /status-page/{subdomain}/subscribe | Public endpoint (no API key required). Confirmation flow is double opt-in. |
Common questions
Can both run in parallel during migration? Yes, and that is the recommended path. The agent reports to Observer; the Statuspage API stays in place until DNS cutover. Subscribers can be on either system during overlap.
What about historical metric values? Observer's history starts when the agent first reports. Statuspage does not offer a metric export to backfill, because Statuspage does not store metric values; it stores manual verdicts. The 90-day incident timeline is what migrates.
How do I keep on-call alerting unchanged? Recreate the webhook subscription. Most alerting integrations (PagerDuty, Slack, Microsoft Teams) accept generic JSON webhooks with HMAC signatures. The signature scheme is described in Webhook payload reference.