The estate, measured now
All systems operational · 006 / 006 passing
All 6 probed services are passing their content assertions from every reporting vantage.
probed just now · worst of every vantage, never a merged green
Platform Operational
The platform at app.conormis.com serves its real shell markup.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
The platform worker's health document names itself and its version.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
The public face renders the catalog shell in every public mode.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
Identity Operational
The OIDC Provider metadata — the sign-in resolution path for every relying party.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
The exercised sign-in path — the RP redirect lands on the OP's real sign-in page, naming the relying platform.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
The OP's registration door renders the real request form.
Probed from 2 declared vantages; a failure from any of them marks this service.
the home vantage's latency line · per-vantage drill-down
Uptime pools every reporting vantage: a failed probe from any vantage counts. Percentages truncate; a number is never rounded up.
Incidents
Written by a human after the fact, published from the incident rows in the repo. Nothing here is auto-generated prose.
September 2026
2026-09-12 · 2026-09-12T10:51:00Z to 2026-09-12T11:03:00Z
The status page was unreachable for about six minutes and carried stale probe readings for about six more.
During a production audit, an operator (me) misread a stale KV read as evidence that the account's workers were unused duplicates, and deleted the three production workers without first checking which service the public hostname attaches to. The check existed as a one-command API query; it was not run. The deletion removed the custom-domain attachment, the cron schedules, and every worker secret.
The worker was redeployed from main, the domain reattached through the estate's scripted act, the operator token restored from its local copy, a fresh relay-report token set on the status worker and both redeployed relays, and the probe schedule re-registered. The board served its stale-state warning honestly throughout the recovery window.
scripts/attach-custom-domain.sh --check) prints which service owns the public hostname; the
operations manual now requires it before any deletion or
redeployment theory is acted on.2026-09-01 · 2026-09-01T07:00:00Z to 2026-09-01T19:23:00Z
Sign-in (password, passkey, or GitHub) never completes for users whose requests reach the affected network path; pages and read-only endpoints keep answering. The evening window ran ~17:00 to 19:23 UTC.
Affected: id-sign-in, id-auth-route
The identity service's database writes travel from the serving Cloudflare location to the database's primary region. That cross-region write path degraded twice on 2026-09-01 (roughly 07:00 to 07:35 UTC, and again from ~17:00 to 19:23 UTC): reads stay fast while writes (the sign-in's audit record, the passkey challenge, session creation) wait indefinitely, so sign-in pages spin without completing. The service's own code, configuration, and database are verified healthy: the same sign-in requests succeed from unaffected network paths, and direct database queries (reads, writes, and schema operations) answer in under a millisecond via the API for the entire window. A roll-back-then-forward during the evening window did not change the symptom; the deployment was never the cause.
The morning window recovered on its own. For the evening window we enabled read replication across all of the estate's databases (reads now stay local to the user), and the write path recovered at 19:23 UTC; we are pursuing the path's stability with the platform provider.
Objectives vs reality
The declared availability and response objectives, against the measured numbers.
| Service | Declared availability | Actual (30d) | Declared latency | Actual p95 (30d) | ||
|---|---|---|---|---|---|---|
| Conormis front door | 99.9% / 30d | 100% | meeting | p95 ≤ 2 s | 3.5 s | missing |
| Platform health | 99.9% / 30d | 100% | meeting | p95 ≤ 2 s | 125 ms | meeting |
| Public catalog | 99.9% / 30d | 100% | meeting | p95 ≤ 2 s | 1.5 s | meeting |
| Identity discovery | 99.9% / 30d | 100% | meeting | p95 ≤ 2 s | 125 ms | meeting |
| Sign-in chain | 99.9% / 30d | 100% | meeting | p95 ≤ 2.5 s | 750 ms | meeting |
| Identity registration | 99.9% / 30d | 100% | meeting | p95 ≤ 2 s | 125 ms | meeting |
Actuals come from the same per-minute probes as the cards above, pooled across every reporting vantage (a failed probe from any vantage counts). Percentages truncate at two decimals and the latency p95 is computed from bucketed per-minute probe latencies. A number is never rounded up to meet a target.
Subscribe
The incident timeline as a feed: RSS 2.0 or Atom. The maintenance windows as a calendar: iCal.