Incident Composer

ready · a live incident 2h 14m old with 4 updates behind it — publishing really appends to the thread, moves the ticked components and re-seeds the form; pick Resolved and every selection is forced back to operational before the confirm

Post an incident update

Elevated error rates on the write API

Open 2h 14m · 4 updates · last 34m ago

The story so far

Write the next chapter, not the same one again.

IdentifiedAug 18, 2026, 1:58 PM UTC34m agoLatestThe pool rollback is deployed to 3 of 5 write nodes. Error rates on the rolled nodes are back to baseline. The remaining two nodes follow in the next 20 minutes.
IdentifiedAug 18, 2026, 1:05 PM UTC1h agoThe cause is connection pool exhaustion on the primary write cluster, left behind by this morning's routine failover. We are rolling the pool size back to its pre-failover value.
InvestigatingAug 18, 2026, 12:44 PM UTC1h agoWrite errors are running at roughly 12% of requests. The dashboard is slow because it retries failed writes. We have not found the cause yet.

State

The cause is known. Say what it is and what happens next.

Repeats the current state — subscribers will see two Identified updates in a row.

Affected components

Tick what this update speaks for, then set what each one is doing.

Incident impact Major, the worst of 3 selected components.

Message

A message is required. Subscribers only ever see what you write here.

Preview

Exactly what each channel delivers.

[Elevated error rates on the write API] Identified

Posted Aug 18, 2026, 2:32 PM UTC

Your message appears here.

Write APIPartial outage
Web dashboardDegraded performance
Webhook deliveryDegraded performance

You are receiving this because you subscribed to updates for this status page.

{
  "channels": [
    "email",
    "sms",
    "webhook"
  ],
  "components": [
    {
      "id": "api-write",
      "impact": "partial_outage"
    },
    {
      "id": "dashboard",
      "impact": "degraded"
    },
    {
      "id": "webhooks",
      "impact": "degraded"
    }
  ],
  "destinations": 1570,
  "impact": "major",
  "incidentId": "inc_7f3a2",
  "message": "",
  "postedAt": "2026-08-18T14:32:00.000Z",
  "smsSegments": 1,
  "state": "identified"
}

POSTed to 12 endpoints, each signed with its own secret — no secret is ever printed here.

Notification reach

Destinations, not people: one person on email and SMS is counted twice.

Email1,240 inboxes79%
SMS318 phones20%
Webhooks12 endpoints1%

1,570 destinations armed · the percentages split exactly this total · 318 SMS messages at 1 segment each

Write a message to enable publishing — an update with no words tells subscribers nothing.

ready · async publish against a flaky status-page API — onPublish returns a Promise, so Publish shows its pending state for 0.8 s; the first attempt rejects with “Status page API timed out” and the typed message stays put beside the error, and publishing again goes through

Post an incident update

Elevated error rates on the write API

Open 2h 14m · 4 updates · last 34m ago

The story so far

Write the next chapter, not the same one again.

IdentifiedAug 18, 2026, 1:58 PM UTC34m agoLatestThe pool rollback is deployed to 3 of 5 write nodes. Error rates on the rolled nodes are back to baseline. The remaining two nodes follow in the next 20 minutes.
IdentifiedAug 18, 2026, 1:05 PM UTC1h agoThe cause is connection pool exhaustion on the primary write cluster, left behind by this morning's routine failover. We are rolling the pool size back to its pre-failover value.
InvestigatingAug 18, 2026, 12:44 PM UTC1h agoWrite errors are running at roughly 12% of requests. The dashboard is slow because it retries failed writes. We have not found the cause yet.

State

The cause is known. Say what it is and what happens next.

Repeats the current state — subscribers will see two Identified updates in a row.

Affected components

Tick what this update speaks for, then set what each one is doing.

Incident impact Major, the worst of 3 selected components.

Message

A message is required. Subscribers only ever see what you write here.

Preview

Exactly what each channel delivers.

[Elevated error rates on the write API] Identified

Posted Aug 18, 2026, 2:32 PM UTC

Your message appears here.

Write APIPartial outage
Web dashboardDegraded performance
Webhook deliveryDegraded performance

You are receiving this because you subscribed to updates for this status page.

{
  "channels": [
    "email",
    "sms",
    "webhook"
  ],
  "components": [
    {
      "id": "api-write",
      "impact": "partial_outage"
    },
    {
      "id": "dashboard",
      "impact": "degraded"
    },
    {
      "id": "webhooks",
      "impact": "degraded"
    }
  ],
  "destinations": 1570,
  "impact": "major",
  "incidentId": "inc_7f3a2",
  "message": "",
  "postedAt": "2026-08-18T14:32:00.000Z",
  "smsSegments": 1,
  "state": "identified"
}

POSTed to 12 endpoints, each signed with its own secret — no secret is ever printed here.

Notification reach

Destinations, not people: one person on email and SMS is counted twice.

Email1,240 inboxes79%
SMS318 phones20%
Webhooks12 endpoints1%

1,570 destinations armed · the percentages split exactly this total · 318 SMS messages at 1 segment each

Write a message to enable publishing — an update with no words tells subscribers nothing.

empty · no incident to update; onDeclareIncident is deliberately not wired here, so the panel ends in a sentence instead of a button that would do nothing

Post an incident update

Subscribers only ever see what you write here.

No open incident

Updates belong to an incident. Declare one and this composer will write the first entry your subscribers read.

loading · the heading survives because it is known before the incident arrives; the skeleton mirrors thread / state picker / message / preview, and its pulse stops under prefers-reduced-motion

Post an incident update

Subscribers only ever see what you write here.

error · the incident could not be loaded, so nothing is publishable and no reach figure is claimed — onRetry is wired, so the button does something real (fired 0×)

Post an incident update

Subscribers only ever see what you write here.

The incident couldn't be loaded

incident-api answered 503 three times in a row, so the update queue is unreachable.