System Status

What crosses the wire

• What is reported

  One state per component rather than one for the platform, plus the incident open against it. Payment processing, the gateway, webhook delivery, the dashboard and terminal connectivity fail independently and are shown that way.

• What an incident entry carries

  What is affected, what is not, when it started, what has been established so far, and updates as they are confirmed rather than as they are guessed. The resolution note follows once the cause is understood.

• What you should correlate it with

  Your own error codes and request ids. An incident timeline plus your logs is what separates a platform event from a change you shipped an hour earlier and had forgotten about.

When to use it

• During an incident

  Confirm platform state before escalating an integration bug, and before rolling back a release that had nothing to do with it.

• In due diligence

  Incident history shows how issues are communicated and how quickly they are resolved, which is more informative than any single availability figure.

• When writing your own runbook

  Component granularity tells you which of your systems degrade together, and therefore which fallbacks are worth building.

How to implement System Status

What fails, and how you find out

• Reading one indicator and stopping

  A platform marked operational can still have one degraded component. Check the component your integration depends on, which for most applications is webhook delivery rather than authorization.

• No plan for delayed events

  If webhook delivery lags, payments still authorize and your orders still need updating. An application with no queue and no backfill query has no way to catch up once delivery resumes.

• Escalating without evidence

  A ticket saying payments are failing is slower to act on than one carrying request ids, error codes and a timestamp range. The status page tells you which of those support already knows about.

• Alerting only on total failure

  Most incidents show up in your metrics first, as a rising decline rate or a growing gap between payments created and events processed. Alert on those, and use status to explain what you already detected.

Sandbox versus production

• Status covers production

  The page reports the environment your customers are in. Sandbox availability is not the number an incident is measured against, so a sandbox failure during an incident is not evidence of scope.

• Degradation is worth rehearsing in sandbox

  You cannot schedule a production incident, but you can point a sandbox integration at a deliberately broken webhook endpoint and watch what your application does while events pile up.

• The commitment is scoped

  The gateway API carries a 99.9% uptime service level. Other components are reported on the status page on their own terms, and the incident history is the honest record of how each has behaved.