Park Graph Status & Incident Communication

The QR code on a parking sign is the front door for every driver, so it is the first flow Park Graph built an automated check for. A scheduled job, set to run every 60 seconds, requests the QR link of a dedicated test lot and follows every hop the way a phone would: HTTP redirects and meta refreshes, up to 10 hops, within 15 seconds. The run passes only if it ends on parkgraph.com, the final page returns status 200, and the pay page quotes exactly the rate stored for that lot. A redirect to the wrong host, an error page, a missing rate, or a rate that disagrees with the database all count as failures.

A single blip is not an outage. When an attempt fails, the job waits 5 seconds and tries once more; only a second miss is recorded as a failure. The first confirmed failure emails the Park Graph team, a reminder follows every hour while the check keeps failing, and a recovery note goes out on the next pass. Each run is stored for 30 days, and the card above reads the last 24 hours of them. Because the card is built from recorded runs only, it cannot claim the check is running when it is not: with no run in 5 minutes it shows Check paused, with none in 24 hours it shows Not running, and if this page cannot reach the results it shows Unavailable rather than an old Operational.

The check identifies itself with a labeled user agent, and every scan of the test lot is excluded from analytics, so synthetic traffic never inflates an operator's scan counts. The public card shows pass or fail, times, and the failure reason in plain words; it never exposes URLs, hosts, or rates.

Payment is where an outage costs operators money, so the QR check has a partner that finishes the job. In the same 60-second job, the payment check acts as a driver on the same test lot: it starts a 30-minute parking session through the checkout the pay page uses, pays with Stripe's test Visa, and asks the server to start the session, exactly as the pay page does after a card is accepted. The run passes only if Stripe authorizes the payment for exactly the session's price, the session activates, and it is saved as paid.

Then it cleans up: the authorization is cancelled and the test session is deleted, so nothing is captured, kept, or paid out. It cannot charge a real card. It runs only in Stripe test mode and refuses to run with a live key, and the checkout pays in test mode only for the lot flagged as a test lot. Before paying, it confirms the payment belongs to that lot, and stops if not. When it refuses to run, it records nothing, so its card says Not running rather than pretending to pass.

The rules match the other checks: a miss is retried once, 5 seconds later, before it is recorded as a failure, and failures are emailed to the team. Its card shows the failing step in plain words, such as the card not being authorized or the session not starting, and never shows amounts, cards, or IDs.

Operators reach Park Graph through the dashboard, and AI agents and integrations reach it through the public API, so those are the next two surfaces with automated checks. Both run in the same 60-second job as the QR check and are read-only: they never sign in, never write data, and never touch payments.

The dashboard check opens the dashboard signed out, the way a returning operator's browser would, and follows every redirect. It passes only if it lands on the sign-in page at parkgraph.com with status 200 and the sign-in page's own content, so an error page, a redirect loop, or a redirect to the wrong host counts as a failure. The API check calls the public health endpoint at /api/v1/health and passes only if it answers on parkgraph.com with status 200, a readable health answer, and its database reported as up.

The rules match the QR check exactly. A miss is retried once, 5 seconds later, before it is recorded as a failure. Each check stores its runs separately for 30 days, emails the team on its own first confirmed failure, hourly while it keeps failing, and on recovery, and has its own live card above. One check failing never changes another check's card.

Operators can sign in with Google, and that button depends on settings outside Park Graph's code: the sign-in app registered with Google, and the Google settings in Park Graph's sign-in service. If either is deleted, disabled, or changed, the button leads to an error page while every other check stays green. So a separate job, built to run every 5 minutes, starts Continue with Google signed out, the way an operator's browser would, and follows each redirect to Google.

It passes only if Google answers with its own sign-in page for Park Graph's app. It fails if the sign-in service refuses to start Google sign-in, if Google shows an error page (for example because the app was deleted or the return address is no longer allowed), or if Google opens sign-in for a different app. It never enters an account, so it cannot catch a problem that only appears after an operator signs in. It runs every 5 minutes rather than every 60 seconds because what it catches are configuration changes, not momentary blips. Otherwise the rules match the other checks: one retry 5 seconds later, its own 30-day history, team emails, and its own live card above, which shows Check paused after 11 minutes without a run.

A status page that describes monitoring it does not have is the most common credibility problem in trust documentation. It reads well until the day something breaks and nobody was watching. Park Graph chose the plainer path: describe what is actually built, let the live cards report whether each check is running, mark everything else as planned, and move items across only when they ship. The payment, dashboard, Google sign-in, and API checks moved across that way: they were listed here as planned until they were built.

The planned work, roughly in order: webhook delivery checks and Stripe webhook health, since receipt delivery depends on Stripe webhooks reaching us quickly; checks from more than one region; real-user telemetry for latency, error rate, and payment success; an incident log on this page; and notifications by dashboard banner, driver receipt note, email, RSS, and webhook.

There are two public ways to follow the checks. Keep this page open, because the live cards refresh every 30 seconds, or poll the public JSON the cards read at /api/status/qr-check, /api/status/payment-check, /api/status/dashboard-check, /api/status/google-signin-check, and /api/status/api-check. Each returns the current state, recent runs, the 24-hour pass rate, and the last failure label for its own check. Inside Park Graph, a confirmed failure is emailed to the team.

Nothing is pushed to operators, drivers, or subscribers yet. Planned: an operator dashboard banner with optional SMS for outages; a note on the receipt of any driver whose session was affected by a confirmed incident; and email, RSS, and webhook subscriptions, so an AI agent can route around a degraded payment surface instead of failing silently. Until those ship, this page and its JSON are the only public status channels.

For any incident that affected payments or driver-facing flows, Park Graph publishes a post-mortem within 5 business days of resolution. It 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 fixed format is deliberate: procurement reviewers want to compare incidents without relearning a layout each time.

While the checks are running, each live card reports a measured 24-hour pass rate, calculated from the runs its check actually recorded. What this page does not report is a single uptime figure for the whole platform. With five surfaces covered by automated checks, a platform number would quietly claim coverage of webhook delivery and live payments that does not exist yet. Check history is also kept for 30 days, which is too short for 90- or 365-day windows. Both gaps are on the planned list above.

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. Naming exactly what is checked, showing the raw pass and fail strip, and publishing the same data as public JSON leaves none of those tactics available, and lets any reader check the math themselves.