> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from Statuspage

> Move components, subscribers, and integrations 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.

> [!NOTE]
>
> **Import tool**
>
> The [Statuspage importer](https://docs.use.observer/docs/guides/import-from-statuspage.md) copies
> components, incident and maintenance history, and consenting email
> subscribers into an Observer page in one step. Use it for the steps
> below that move data, then follow the rest of this guide.

## 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, or set a manual metric's status with `POST /api/v1/metrics/{id}/status`. |
| Subscribers (email / SMS / Slack / webhook) | Page subscribers + Alerts destinations | Email, Slack, Teams, and webhook subscribers re-subscribe through the new page's subscribe form (see [Subscribe to a status page](https://docs.use.observer/docs/guides/status-page-subscriptions.md)). SMS is not supported. Your own team's Slack, PagerDuty, Teams and other channels are destinations under **Alerts**. |
| Public status page domain | Status page subdomain | Both products serve a customer-facing domain. Plan a DNS cutover window. |
| Maintenance windows | Update with `Maintenance` type | Posted in advance, displays on the page during the window. |

## Steps

**1. 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 (to keep as an archive you can link to
  from 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.

**2. Stand up the Observer side in parallel**

Follow [Define your first metric](https://docs.use.observer/docs/quickstart/first-metric.md)
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.

**3. Build the status page**

Open **Status pages** > **New status page** in the Observer console. Recreate
the public-facing layout: title, theme, services, metrics, SLO
strip. The page is reachable on
`<subdomain>.use.observer` immediately, before the DNS
cutover.

If the Statuspage account uses customer-scoped views (visible
under different domains per customer), see
[Configure customer-scoped pages](https://docs.use.observer/docs/guides/customer-scoped-pages.md).

**4. Bring over incident history**

Run the [Statuspage importer](https://docs.use.observer/docs/guides/import-from-statuspage.md).
Past incidents and finished maintenances arrive as published history
with their original dates, and nobody is notified.

**5. Migrate subscribers**

The [Statuspage importer](https://docs.use.observer/docs/guides/import-from-statuspage.md) moves
active email subscribers when you confirm they agreed to hear from
you, and can ask them to confirm with a single email. Invite anyone else to the new page's subscribe form: email your
existing subscribers during the migration window with a link to it.
SMS subscribers need to be re-acquired the same way.

For webhook destinations you operate yourself, add a destination with the
**Generic webhook** channel under **Alerts**, point it at the same endpoint URL, and pick
the events that match what the consumer expects. See
[Configure outbound webhooks](https://docs.use.observer/docs/guides/outbound-webhooks.md) and the
[Webhook payload reference](https://docs.use.observer/docs/reference/webhook-payloads.md).

Slack, Teams, and webhook subscribers outside your team reconnect from the
new page's subscribe form, the same way email subscribers do. Their
webhook payloads are described in the
[subscriber webhook reference](https://docs.use.observer/docs/reference/subscriber-webhooks.md).

**6. Cut over DNS**

When the Observer page renders correctly and all subscribers are
migrated, add the hostname (commonly `status.<domain>`) in the
page's **Custom domain** section, CNAME it to `cname.use.observer`,
and switch over once it reads **Active**. See
[Custom domain](https://docs.use.observer/docs/guides/custom-domain.md).

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](https://docs.use.observer/docs/guides/incidents-via-api.md) 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](https://docs.use.observer/docs/concepts/manual-metrics.md). | |
| (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 starts and completes the window automatically at the configured times. |
| `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 https://<subdomain>.use.observer/subscribe` | Public endpoint (no API key required) behind the page's subscribe form. Body: `{"email": "..."}`, or `{"channel": "slack" \| "teams" \| "generic_webhook", "url": "..."}`. Email uses double opt-in; channels are confirmed by a test message. |

## 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; past metric
values are not imported.

**How do I keep on-call alerting unchanged?**
Recreate each destination on the **Alerts** page (Slack, Teams,
PagerDuty, generic webhook). See
[Configure outbound webhooks](https://docs.use.observer/docs/guides/outbound-webhooks.md) for
the generic webhook and its signature scheme.

> [!NOTE]
>
> **Talk to support**
>
> For large accounts, contact support before you start.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.