React Status Page

A vendor without a status page is asking customers to learn about outages from their own monitoring. This is the per-service uptime history and the incident thread that go with it.

Degraded — some systems affected

Last updated 14:40 UTC · refreshes every 60s

Subscribe
  • Device API

    Provisioning, attestation, and telemetry ingest

    Operational
    90 days ago99.96% uptimetoday
  • Management console

    Web dashboard and fleet management

    Operational
    90 days ago99.99% uptimetoday
  • OTA delivery

    Firmware manifest and artifact distribution

    Degraded
    90 days ago99.90% uptimetoday
  • Key management

    HSM-backed key store and rotation

    Operational
    90 days ago99.99% uptimetoday

Recent incidents

  • minor

    Elevated OTA manifest build latency

    2026-07-22

    Affected: OTA delivery

    1. monitoring14:32 UTC

      Manifest build queue has drained. We are monitoring throughput before declaring resolved.

    2. identified13:58 UTC

      A signing key rotation left a stale cache entry, causing repeated manifest rebuilds.

    3. investigating13:41 UTC

      We are investigating reports of slow firmware manifest generation.

  • maintenance

    Scheduled maintenance — key management failover test

    2026-07-14

    Affected: Key management

    1. resolved03:20 UTC

      Failover test completed. RTO measured at 3m 41s, within our 4-hour commitment.

    2. monitoring02:00 UTC

      Planned failover initiated. Key operations served from the secondary region.

  • major

    Partial Device API degradation in eu-central-1

    2026-05-20

    Affected: Device API, Management console

    1. resolved09:12 UTC

      All ingest endpoints recovered. Post-incident review published in the trust centre.

    2. identified08:05 UTC

      An upstream provider network event degraded ingest for roughly 38 minutes.

Installation

npx shadcn@latest add "https://kelvinui.com/registry/status-page.json"

Props

PropTypeDescription
servicesStatusService[]{ id, name, description?, state, history }
incidentsStatusIncident[]{ id, title, date, severity, affected?, updates }
updatedLabelstringFreshness line under the banner
subscribeHrefstringWhere to subscribe to updates

Overall status is the worst service

The banner takes the minimum health across every service — it never rounds up to green. A page that says "All systems operational" while one component is degraded is worse than having no status page, because it converts a transient outage into a credibility problem. The ranking is explicit: outage beats degraded beats maintenance beats operational.

maintenance is a distinct state rather than a flavour of outage, so planned work does not look like a failure — and does not quietly hide one either.

Incident threads, not incident headlines

Each incident carries an ordered list of updates with investigating, identified, monitoring, and resolved statuses. The thread is the useful artefact: a customer wants to see that you found it, understood it, and confirmed the fix — with times attached. A single "resolved" line reveals nothing about whether you knew what happened.

Uptime bars derive their colour from the daily percentage when no explicit state is given (≥99.9% operational, ≥95% degraded, below that an outage).

The printed average is clamped so it never rounds up to a perfect 100.00%. A 90-day window containing a single 99.85% day averages to roughly 99.996%, which naive formatting renders as 100.00% — sitting directly beside a strip with a visible amber bar, so the page contradicts itself. Anything short of a genuinely flawless window displays as at most 99.99%. It is the same rule as the overall banner: never round up to green.

Feed real measurements; a status page with invented history is the single fastest way to destroy the trust it exists to build.

New components every week

Get the week's new Kelvin UI components and templates in one short email. No spam, unsubscribe anytime.