Park Graph Status & Incident Communication

A status page that publishes a "99.x% uptime" number on day one without a measured history is the most common credibility violation in trust documentation. Park Graph chose the harder path: publish what we can verify, label what is in progress, and add the measured uptime number when it actually means something.

That means today the status page surfaces classification plus a manual incident log; the rolling-window uptime number lights up once the public history backfill is complete. The plumbing (synthetic checks, real-user telemetry, Stripe webhook health, notification fan-out) is already in place; what is being built is the public-facing presentation of the historical record.

Synthetic checks run from multiple regions every 60 seconds against the QR landing flow, payment flow, dashboard, public API, and webhook delivery. Each check measures availability and latency; sustained failure on any check raises an alert and updates the per-surface classification.

Real-user telemetry covers what synthetic checks cannot — the actual P50/P95 latency, error rate, and payment-success rate a user experiences from their device. The orchestrator weights real-user signals heavier than synthetic when the two disagree, because what a user actually sees is the ground truth.

Stripe webhook health is its own signal because payment receipt delivery depends on Stripe webhooks reaching us quickly. A Stripe webhook backlog manifests as delayed receipts, which is a real driver-facing degradation even when the rest of the system is operational.

The on-call engineer can post a manual update at any time. A known maintenance window, a confirmed regional issue, or a third-party outage that does not yet show in the synthetic signal can all be communicated proactively.

Operators get the in-app dashboard banner automatically. They can also opt into SMS for outage-class incidents by adding a phone number in their notification settings. The dashboard banner clears the moment the orchestrator classifies the surface as operational again.

Drivers do not subscribe to anything; if their session was affected, the receipt thread carries the explanation and any refund. AI agents using the API can subscribe to a status webhook so a degraded payment surface can route to a fallback (for example, surfacing an in-person operator phone number) rather than failing silently.

Anyone can subscribe to email updates from the status page or to the RSS feed at status.parkgraph.com/feed.xml. The feed is public and unauthenticated.

A Park Graph post-mortem is structured the same way every time: a one-paragraph customer-impact summary at the top (what users saw, when, on which surface), a timeline (detection, escalation, mitigation, resolution), a root-cause section (what failed and why), a blast-radius section (which users, which sessions, which payments), and the corrective actions with target dates.

Post-mortems are blameless in tone but specific in mechanics — we do not redact the technical detail just because it shows the failure was a foot-gun in our own architecture. The point of the post-mortem is to make the next incident of the same shape impossible, which requires being honest about the shape of this one.

The current status page reports three things in real time. It reports the live classification of each platform surface (driver web flow, operator dashboard, public API, marketing site) as operational, degraded, or outage. It reports the active incidents, with a description, a start time, and a most-recent update. And it reports the resolved incidents from the last 30 days, each linked to its post- mortem entry. What it does not yet report is a fixed numerical uptime over a defined window. That number is in progress and will be added once the public history backfill completes; in the meantime we would rather show no number than a fabricated one.

The reason the page is built that way is that uptime numbers are easy to manipulate and hard to audit from the outside. A vendor can quietly redefine the surfaces that are measured, exclude classes of incident from the calculation, or pick a measurement window that flatters the number. None of those tactics are available to a status page that reports raw incidents and lets the reader calculate uptime themselves. Once the public backfill is complete, the rolling 30-day, 90-day, and 365-day uptime will be reported alongside the raw incident log so any reader who wants to check the math can do so.

Subscribers to the status page receive notifications via three channels: an email per incident, an RSS feed for machine consumption, and a webhook for operators that want to ingest incident events into their own monitoring stack. A new incident triggers an initial notification within 15 minutes of internal detection; subsequent updates follow on a cadence that depends on severity (critical: every 30 minutes, high: every 2 hours, medium: every 4 hours). A resolved-incident notification includes the time-to-detect, time-to-mitigate, and a link to the post-mortem when available.

Post-mortems are published within 10 business days of incident resolution and follow a fixed format: incident summary, customer impact, timeline, root cause, contributing factors, action items, and what we got right. The format is stable on purpose — readers (especially procurement reviewers) want to compare across incidents without relearning a layout each time.