Platform status

The check at your counter doesn’t wait on our cloud.

Laurel’s most important availability property is architectural: the verification decision happens on the reader. A platform incident can delay a report or a dashboard — it cannot stop your door or your lane.

01 · Components

What can degrade, and what it would mean.

Each platform component fails toward inconvenience, not toward a stopped operation. This is the degradation map we hold ourselves to.

Component If it degrades

verification Unaffected by platform incidents — the decision is made on the reader On-device by design, not by failover.

api Outcome reporting and fleet signals queue until service resumes

portal Dashboards and administration pause; readers keep operating

reporting Aggregates catch up after ingestion resumes; no outcomes are lost to display lag

02 · Incident communication

Directly, from people who know what happened.

During pilots and early rollouts, incident notifications go to your operational contacts directly — what degraded, what it affected, and when it resolved. A public, live component feed will publish on this page as the fleet grows; until then we would rather route updates to the people running readers than perform a dashboard for the public.

Questions about an active issue? Contact us and mark the message operational.

Why this page is short

The strongest status page is a small dependency graph.

One API surface, one database, one portal — and a verification path that needs none of them at the moment of truth.

Review the architecture See the boundary