Platform status

The status page is for humans. Everything on it is also available in three machine-readable forms, so a pager, a dashboard, or a feed reader can watch platform health without polling HTML.

The status document

Two paths serve the identical payload. The second exists so you have a stable, versioned URL that looks like the document it is.

Both are public (no API key, no session) and rate-limited at 60 requests per minute per client. A status endpoint that required credentials would be useless during the outage you built it for.

{
  "schema_version": "1.1",
  "overall": "operational",
  "headline": "All systems operational",
  "monitoring_configured": true,
  "generated_at": "2026-07-27T12:00:00+00:00",
  "components": [
    { "name": "Trading", "status": "operational", "impacted_alarms": [] }
  ],
  "dependencies": [
    { "name": "Database", "status": "operational", "latency_ms": 1.5 }
  ],
  "history": [
    {
      "date": "2026-07-26",
      "overall": "degraded",
      "components": { "Trading": "degraded" }
    }
  ]
}

overall, each component status, and each dependency status are one of operational, degraded, or down. overall is the worst of them.

monitoring_configured — read this field

Component states are alarm-fed where monitoring is configured, and this boolean tells you whether that is true in the environment you are talking to.

• true — a fresh status artifact is present, so the components array reflects live alarm state.
• false — no fresh artifact. The components array is sitting at its non-breaching baseline, and only dependencies (live database and cache probes, with real latency) are measured. Treat component rows as “not currently monitored here”, not as “confirmed healthy”.

The flag is derived, not declared: it is true exactly when a recent artifact exists, and it flips back to false on its own when the publisher stops. There is no way for it to claim monitoring that is not running.

history

history is the accrued daily rollup: one entry per day the publisher actually observed, oldest first, carrying the worst state seen that day overall and per component.

Two properties matter more than the shape:

• It is never back-filled. The series begins on the first day the publisher ran, not on the day the platform launched. A short history means a short record, not a good one.
• An unobserved day is absent, not green. There is no zero-filling and no “assume operational” for a gap.

history is [] — never null, never omitted — until the first day is recorded.

Version policy

schema_version is the field to pin against. It follows a written rule:

Current: 1.1 — 1.0 plus the additive history field.

The status.changed webhook

Subscribe an endpoint to status.changed to be pushed transitions instead of polling. It rides the same signed, retried, dead-lettered delivery system as every other Drazill event — see Webhooks for signature verification and retry semantics.

Three things to know before you build on it:

• It is edge-triggered, not level-triggered. You get an event when something changes. A four-hour outage sends two events — one going in, one coming out — not one per publish cycle.
• It is a state diff, not an incident. The payload names the components that moved and their old and new states. Drazill has no incident entity, so the event does not pretend to one: there is no incident id, no open/resolved lifecycle, and no post-mortem link.
• It is a broadcast. The event is not scoped to a user, and it is delivered to subscribed endpoints in both livemodes — a test-mode integration cares that trading is degraded exactly as much as a live one does.

{
  "schema_version": "1.1",
  "overall": "degraded",
  "previous_overall": "operational",
  "generated_at": "2026-05-08T12:00:00Z",
  "components": [
    {
      "name": "Wallet & Payments",
      "previous_status": "operational",
      "status": "degraded"
    }
  ]
}

components lists only what moved. A component appearing for the first time is not a transition — it has no previous state to report — so it is omitted rather than given an invented one. The list can be empty when only overall moved.

The RSS feed

https://drazill.com/feeds/status.xml

No key, no account, no webhook endpoint to host. One item per recorded day on which something was degraded or down, plus one item for the current state while it is not operational. A <ttl> of 5 minutes hints the poll cadence.

A healthy platform’s feed is empty, and that is the correct output — the feed carries events, not reassurance. A clean day produces no item, and if the status service itself is unreachable the feed serves a valid empty channel rather than an all-clear it cannot vouch for.

Where each surface is armed

The publisher that produces artifacts, accrues history, and emits status.changed is behind a flag, so what you see depends on the environment:

When the publisher is not running, or cannot read alarms, the endpoints stay up and honest: monitoring_configured reads false, history stays as-is, and the live dependency probes still report. Nothing degrades into a fabricated green.