Status feed

The public status feed behind the status page, the RSS, Atom and JSON incident feeds, email updates, and how to read them.

The status page reads one public JSON document from the Tickwire status service. The service runs apart from the API, so it keeps answering when the platform doesn’t. You can read the same feed to show Tickwire’s status in your own dashboard, or follow incidents in a feed reader.

GET https://status.tickwire.io/api/v1/status.json

The status page shows the feed’s current address. Every endpoint on this page is public, needs no key and allows cross-origin reads.

What’s available now: the JSON feed, RSS, Atom and JSON Feed. Not yet: email updates. They switch on when an email provider is configured. Until then, subscribing answers email_notifications_unavailable and the feed says "subscribe": {"email": false}.

What it measures

Each component’s status comes from real probes run every 30–60 seconds from outside the platform:

A component with no probe set up yet is listed separately as Not monitored yet (the feed’s not_monitored list). We have no evidence either way for it, so it is never shown green or red and it does not count towards the overall status. A probed component with no recent result shows unknown, and no data in its daily bars. Services we don’t run yet are not listed.

Endpoints

The JSON endpoints are cacheable for 15 seconds, the incident feeds for 60.

Shape (tickwire.status.v1)

{
  "schema": "tickwire.status.v1",
  "generated_at": "2026-09-27T12:00:30Z",
  "page": { "name": "Tickwire", "url": "https://status.tickwire.io" },
  "status": { "indicator": "none", "description": "All Systems Operational" },
  "components": [
    {
      "id": "gateway",
      "name": "API gateway",
      "group": "Platform",
      "description": "The public REST and WebSocket entry point.",
      "region": null,
      "account_class": null,
      "status": "operational",
      "measured_status": "operational",
      "updated_at": "2026-09-27T12:00:21Z",
      "probes": [
        { "id": "gateway-healthz", "name": "Gateway liveness", "kind": "http", "state": "up",
          "fresh": true, "checked_at": "2026-09-27T12:00:21Z", "latency_ms": 41.2, "detail": "HTTP 200",
          "region": null, "account_class": null }
      ],
      "uptime": { "24h": 100.0, "7d": 99.98, "30d": null, "90d": null },
      "history": [
        { "date": "2026-09-26", "uptime_pct": null, "status": "no_data",
          "samples": { "up": 0, "degraded": 0, "down": 0, "paused": 0 }, "avg_latency_ms": null },
        { "date": "2026-09-27", "uptime_pct": 100.0, "status": "operational",
          "samples": { "up": 2400, "degraded": 0, "down": 0, "paused": 0 }, "avg_latency_ms": 44.0 }
      ]
    }
  ],
  "not_monitored": [
    { "id": "webhooks", "name": "Webhook delivery", "group": "Platform",
      "description": "Signed webhook events reaching a canary endpoint." }
  ],
  "groups": [ { "name": "Platform", "status": "operational", "components": ["gateway"] } ],
  "regions": [],
  "account_classes": [],
  "incidents": { "active": [], "recent": [] },
  "maintenances": { "active": [], "upcoming": [] },
  "postmortems": [],
  "subscribe": {
    "email": false,
    "rss": "https://status.tickwire.io/api/v1/feed.rss",
    "atom": "https://status.tickwire.io/api/v1/feed.atom",
    "json": "https://status.tickwire.io/api/v1/feed.json"
  },
  "power": {
    "configured": true, "paused": false, "state": "running",
    "since": null, "checked_at": "2026-09-23T12:00:00Z", "description": null
  }
}

history is oldest first and covers 90 days by default. Uptime counts degraded as available. A check that finds something down while the platform is paused on purpose counts under samples.paused and is left out of every uptime figure: a planned sleep is not downtime. The full JSON Schema is published at /schemas/status-feed.schema.json.

Truth rules

The status page applies these, and we recommend you do the same:

1. If generated_at is more than 5 minutes old, treat everything as unknown.
2. A component that says operational or degraded_performance but whose updated_at is more than 5 minutes old, or missing, is unknown.
3. A day with uptime_pct: null is “no data”, never green.
4. An unrecognised status value is unknown.
5. The overall status is the worst component status, and unknown ranks worse than operational. Only components count; not_monitored entries never do. With no monitored component at all, the overall status is unknown.
6. If the feed can’t be fetched, or isn’t a tickwire.status.v1 document, say the feed is unreachable. Don’t show the last state you saw as current.

Incident feeds

feed.rss, feed.atom and feed.json carry one entry per incident or maintenance, newest activity first (up to 50). An entry’s updated time is its latest update, so your reader shows it again when it changes. Its text lists every update and, once published, links the postmortem. An empty feed means we haven’t posted an incident.

Email updates

When email is available (subscribe.email is true):

curl -X POST https://status.tickwire.io/api/v1/subscriptions \
  -H 'content-type: application/json' -d '{"email":"you@example.com"}'

• The answer is always 202 with the same body, whether or not the address is already subscribed.
• We send a confirmation link. Nothing else is sent until you confirm it. The link expires in 48 hours.
• Every incident email has an unsubscribe link.
• Limits: 5 requests per hour from one IP address (IPv6: per /64) (rate_limited). One address gets at most one confirmation email every 10 minutes and 3 a day, whoever asks. Requests beyond that still get the same 202, and no email is sent.

When email isn’t available the endpoint answers 503 email_notifications_unavailable, and its message lists the feed URLs.

Postmortems

After a significant incident we publish a postmortem on the incident’s page (/status/incident/?id=N on this site). Published postmortems appear in the feed’s postmortems list and in the incident feeds. None have been published yet.