# Honest status pages after sandbox exit: component status, timeline, and incident updates

> Own an honest status page after sandbox exit: component statuses, incident timeline, severity, subscribers, maintenance windows, and postmortem links.
> By Dave · 2026-09-22
> Source: https://otf-kit.dev/blog/incident-status-page-honest-comms

Sandbox hosts often paint one green badge for the whole product. After you leave Lovable or Bolt and own the backend, that badge becomes a marketing lie the first time only the checkout API is down. An honest status page shows component-level health, an incident timeline with severity, subscriber updates, scheduled maintenance windows, and a postmortem link when the dust settles — so customers and agents see evidence, not vibes.

This post is about the public communications contract on infrastructure you control: which components you expose, how you refuse fake-green overall status, how you open and update incidents, and how agents (and humans) subscribe to truth. It pairs with [rolling deploys on an owned backend](https://otf-kit.dev/blog/rolling-deploys-owned-backend) (cutover without darkening the fleet) and [structured production logs for agents](https://otf-kit.dev/blog/production-structured-logging-for-agents) (triageable internal truth). It is not [AI-driven infrastructure incidents](https://otf-kit.dev/blog/ai-infra-incidents) (IaC governance), not probe/readiness health-check tutorials, and not deploy strategy. The claim is narrow: own a status page that tells the truth about what is down.

## Model components customers actually depend on

A status page without components is a single boolean. Statuspage defines components as the individual parts of your infrastructure that users depend on — website, API, auth, billing, webhooks — each with its own status ([Show service status with components](https://support.atlassian.com/statuspage/docs/show-service-status-with-components/)). Typical component statuses are operational, degraded performance, partial outage, major outage, and under maintenance.

Start from the buyer path, not from your internal service map. If a customer cannot sign in, charge a card, or call your public API, those three deserve components even if twenty microservices sit behind them. Group related pieces when hierarchy helps, but never hide a customer-visible failure under a single "Platform: Operational" row.

Wire the page base and API identity as env you can review in a PR:

```bash
export STATUS_PAGE_BASE="${STATUS_PAGE_BASE:?set public status page base URL}"
export STATUS_PAGE_ID="${STATUS_PAGE_ID:?set page id}"
export COMPONENT_API="${COMPONENT_API:-$STATUS_PAGE_BASE/api/v1}"
export INCIDENT_WEBHOOK="${INCIDENT_WEBHOOK:?set incident webhook}"
```

Prefer path-only routes relative to `$STATUS_PAGE_BASE` in runbooks (`/api/v1/components`, `/api/v1/incidents`). Do not hardcode hosts in agent prompts; agents should read `$STATUS_PAGE_BASE` and `$COMPONENT_API` the same way they read deploy knobs.

## Refuse fake-green overall status

Fake green is when the page header says "All Systems Operational" while a component users need is degraded or dark. Component status changes alone often do not notify subscribers — incidents do ([What is Statuspage?](https://support.atlassian.com/statuspage/docs/what-is-statuspage/)). So a team that silently flips a component to major outage without opening an incident can leave email and SMS subscribers in the dark while the header still looks fine to casual visitors.

Rules that keep the page honest:

1. Overall status is derived from the worst customer-facing component in scope — never hand-set to green while any public component is degraded or worse.
2. Every customer-visible component degradation opens an incident (or attaches to an open one) so a timeline and notifications exist.
3. Agents that can mutate production may update components only through `$INCIDENT_WEBHOOK` or `$COMPONENT_API` with an incident id — never a silent green flip.

![Fake-green overall badge versus honest per-component statuses](https://cdn.otf-kit.dev/blog/incident-status-page-honest-comms/inbody1-20260922a.png)

## Open incidents with a timeline and severity

Incidents are the narrative customers read. Statuspage models realtime incidents with statuses investigating, identified, monitoring, and resolved ([What is Statuspage?](https://support.atlassian.com/statuspage/docs/what-is-statuspage/)). Google SRE separates operational work from communication so the person fixing the system is not also the only person writing updates ([Managing Incidents](https://sre.google/sre-book/managing-incidents/)).

On an owned backend after sandbox exit, treat the status page as the public face of that communication role:

- **Investigating** — something is wrong; you have evidence (error rate, readiness failures, customer reports) but not yet a root cause.
- **Identified** — cause or blast radius is known; mitigation is in progress.
- **Monitoring** — fix is deployed; watching for recurrence.
- **Resolved** — customer impact ended; postmortem queued if triggers fire.

Severity labels (minor / major / critical, or your product’s equivalent) set expectations. A partial checkout outage is not the same as total API dark. Put severity in the first update so agents scraping `$STATUS_PAGE_BASE` can decide whether to retry, pause jobs, or page a human.

Keep a live incident state document internally (wiki or shared doc) as SRE recommends, and mirror the customer-safe subset onto the public timeline. Do not paste secrets, PII, or internal hostnames into public updates. Correlation ids from structured logs belong in the internal doc; the public page gets impact, ETA ranges you actually believe, and which components are affected.

## Subscriber updates beat support tickets

Subscribers opt in for email, SMS, or webhook notifications when you publish incident updates ([What is Statuspage?](https://support.atlassian.com/statuspage/docs/what-is-statuspage/)). Component subscriptions let users filter noise to the pieces they care about ([Show service status with components](https://support.atlassian.com/statuspage/docs/show-service-status-with-components/)).

After you own the backend, support volume during outages is a tax on the same engineers who are fixing the outage. A status page that auto-notifies subscribers reduces that tax. For agents and partner systems, prefer webhook subscribers pointed at `$INCIDENT_WEBHOOK` consumers that pause scrapers, hold deploys, or surface banners in your own product.

Minimal publish path from a runbook (shape only — use your provider’s API docs for exact fields):

```bash
# Open or update an incident; never silent-green a component without this
curl -sS -X POST "$COMPONENT_API/pages/${STATUS_PAGE_ID}/incidents" \
  -H "Authorization: OAuth ${STATUS_API_KEY}" \
  -H "Content-Type: application/json" \
  -d @- <<'JSON'
{
  "incident": {
    "name": "Checkout API elevated errors",
    "status": "investigating",
    "impact_override": "major",
    "body": "We are investigating elevated error rates on the Checkout API component. Card charges may fail. Next update within 30 minutes.",
    "component_ids": ["${CHECKOUT_COMPONENT_ID}"],
    "deliver_notifications": true
  }
}
JSON
```

Update on a clock (every 30–60 minutes while investigating) even when you have no new root cause. "Still investigating; no change to impact" is honest. Silence is how fake-green cultures form.

## Schedule maintenance instead of surprising customers

Planned work is not an incident surprise. Statuspage scheduled maintenance uses statuses scheduled, in progress, verifying, and completed, with optional auto-notify, 60-minute reminders, and automatic component flips to under maintenance then back to operational ([Schedule maintenance](https://support.atlassian.com/statuspage/docs/schedule-maintenance/)).

When you own rollouts — including the health-gated cutovers in [rolling deploys](https://otf-kit.dev/blog/rolling-deploys-owned-backend) — publish the maintenance window before you touch capacity. Affect only the components that will actually degrade. If agents can schedule deploys, require a maintenance id on `$STATUS_PAGE_BASE` (or an explicit "no customer impact" checkbox reviewed by a human) before the deploy job starts.

## Close with a postmortem link when triggers fire

A resolved incident without learning is a recurring outage. Google SRE treats postmortems as documentation of impact, actions, root causes, and follow-ups — blameless, reviewed, and shared ([Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)). Common triggers include user-visible downtime beyond a threshold, data loss, on-call intervention (rollback, traffic shift), long resolution time, or monitoring failure.

Add a public postmortem link (or a short customer-facing summary that links to a sanitized write-up) once the internal postmortem is reviewed. The status page timeline should not end at "Resolved" with no pointer to what changed. Agents that watch `$STATUS_PAGE_BASE` can then correlate "this class of failure already has a fix in flight" instead of opening duplicate tickets.

![Probe opens incident, updates components, notifies subscribers, resolves, links postmortem](https://cdn.otf-kit.dev/blog/incident-status-page-honest-comms/inbody2-20260922a.png)

## Minimal honest-status checklist for owned backends

Before you call the status page production-ready:

1. Components match customer-visible dependencies (auth, API, checkout, webhooks — not every internal pod).
2. Overall status cannot read operational while any public component is degraded or worse.
3. Customer-visible degradations open incidents with severity, timeline statuses, and `deliver_notifications` on.
4. `$STATUS_PAGE_BASE`, `$STATUS_PAGE_ID`, `$COMPONENT_API`, `$INCIDENT_WEBHOOK`, and `$STATUS_API_KEY` live in deploy config — no hosts pasted into agent prompts.
5. Scheduled maintenance exists for planned capacity work; subscribers get create + reminder notifications.
6. Postmortem triggers are written down; resolved major/critical incidents get a public link or summary.
7. Internal logs stay triageable via [structured production logs](https://otf-kit.dev/blog/production-structured-logging-for-agents); public updates stay free of secrets and PII.
8. Pair with [API timeouts and retries](https://otf-kit.dev/blog/api-timeouts-retries-ai-backends) and [Postgres connection pooling](https://otf-kit.dev/blog/postgres-connection-pooling-production) so agents degrade gracefully while the page tells the truth.

Open Template Forest ships full-stack kits and templates for builders who hit the scaling wall after sandboxed AI builders — when you own the backend, honest status belongs in the same runbook as rolling cutover and structured logs ([templates](https://otf-kit.dev/templates)).

## Sources

- [What is Statuspage?](https://support.atlassian.com/statuspage/docs/what-is-statuspage/) — Atlassian Support
- [Show service status with components](https://support.atlassian.com/statuspage/docs/show-service-status-with-components/) — Atlassian Support
- [Schedule maintenance](https://support.atlassian.com/statuspage/docs/schedule-maintenance/) — Atlassian Support
- [Managing Incidents](https://sre.google/sre-book/managing-incidents/) — Google SRE Book
- [Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/) — Google SRE Book