Status

All systems operational (16 of 16 checks passed).

This page is generated when you load it, from the same report /healthz serves to machines. Each row is a verdict the running service has reached about itself — not a value someone remembered to update, and not a probe that cannot fail. Every row also says when its subject was last looked at, because a verdict reached at boot and a verdict reached a second ago read identically and are not the same claim.

What each check means

• Publish API — how many of the contract's operations this deployment routes. It does not claim any of them would succeed right now; the rows below are where that is decided.
• Metadata store — the database backing Sites, versions and file manifests answers a query.
• Blob storage — the content-addressed directory that holds published bytes is present, listable and writable.
• Stored content — the objects the index names are reconciled against the store, on a cadence, while this process runs. A store that has lost content while the index still lists it is the state that produces 404s for a whole catalogue — and it can begin an hour after a clean boot, which is why this one is re-taken rather than remembered.
• Startup integrity — what the boot found: whether the write-ahead log was intact, the pragmas were as declared, and the index was not older than the store. This row is deliberately about the boot, and its observed stamp says so. It does not tell you to acknowledge anything. An acknowledgement means “delete what is left” and is the only destructive step this service has, so the row that carries a hold names it only while a hold is actually in force — and a hold that has ended says it has ended. Some end without a decision: when every object a rolled-back index stranded has been republished or removed, the hold releases itself and INTEGRITY-ALERT.txt records that no acknowledgement was needed.
• Content integrity — no stored blob has been found to disagree with the hash it is filed under.
• Background scrub — the rotation that re-reads the whole store on a cycle is running, and how much of the last pass it could actually read.
• Write admission — the storage ceiling can be measured and has room, so publishes are being accepted.
• Storage reclamation — whether an incident is holding deletion right now, and whether every store operation is completing. Unlike the row above it this one is a live reading, so it is the one to believe about whether anything is held at this moment.
• Proxy trust — whether this deployment can tell one visitor from another. Every rate limit here is keyed on a client address; behind a reverse proxy whose network is not named in TRUSTED_PROXIES, every request keys on the proxy instead and the limits stop being per-visitor. One person mistyping a password would then lock out every visitor to every private Site. Serving is unaffected, which is exactly why it goes unnoticed.
• Site serving — the host-routed serving tier for {slug}.oi.mrdk.io is loaded.
• Expiry sweeper — nothing past its expiry is still live, and the reclamation pass is completing on its cadence.
• Discovery surface — the machine-readable documents agents fetch (llms.txt, openapi.json, agent.json) are being served.

Incidents

No check is reporting a problem. When one is, the row above carries the finding and the evidence behind it, and this deployment stops calling itself operational.

Checking status from an agent or a monitor

GET /healthz serves this same report as JSON. It is never cached, and it answers 503 when and only when status is failed — a deployment that is degraded but still serving answers 200, because withdrawing it from rotation would take a working catalogue off the network without fixing anything. Both of this deployment’s own probes read this endpoint: the container healthcheck parses the body, so a 200 carrying "status":"failed" could never read green, and the reverse proxy reads only the status code.

curl -sS https://oi.mrdk.io/healthz | jq '{status, writes, notOk}'
curl -sS -o /dev/null -w '%{http_code}\n' https://oi.mrdk.io/healthz

The response carries:

• status — ok, unknown, degraded or failed; the worst of the individual checks, ordered that way. Also sent as the X-Oi-Health response header, so a HEAD request learns it too.
• serving — whether ordinary reads can be answered correctly.
• writes — accepting or refusing.
• summary — the one sentence at the top of this page.
• checks[] — {id, title, status, summary, observedAt, ageMs, basis, evidence} per row. id is stable and is what a monitor should alert on; evidence carries whatever the component that reached the verdict actually knows and its keys vary by check.
• failing[] and notOk[] — check ids, for alerting without walking the array.
• freshness — when this report was assembled, when this process started, and when the store was last reconciled against the index, with the cadence and the measured cost that chose it.

unknown is not a hedge and never means healthy: it is what a check reports when it could not be run at all — the store reconciliation switched off, a corruption count whose query failed, a scrub that has never completed a pass, a store whose directory could not be read (which establishes nothing about the content inside it). A check whose own probe throws is reported as failed with the error attached, never as a passing or an absent one.

How old is this answer?

Every check carries observedAt, ageMs and basis, so “checked a second ago” can be told from “checked at boot, three days ago”. basis is one of:

• request — established while answering the request you are reading.
• recheck — from the periodic reconciliation of the store against the index, with its own timestamp.
• boot — a fact about the boot: the write-ahead log as it was found, the pragma verdict, a hold that is still on record. Re-running these would not make them fresher.
• recorded — read from a durable record that an earlier moment wrote, such as the last scrub pass.

The reconciliation runs on a cadence derived from its own measured cost — it may spend at most 1% of one core, so a small store is re-checked every couple of seconds and a store at this deployment’s object ceiling every half-minute. It is never run per request: this is a public page, and a synchronous walk of the store per page view would be a lever anyone could pull.

curl -sS https://oi.mrdk.io/healthz | jq '.freshness.content'
curl -sS 'https://oi.mrdk.io/healthz?fresh=1' | jq '{status, refresh: .freshness.content.refresh}'

?fresh=1 re-takes it now, for watching a repair land. It is bounded by the same measurement at a higher duty, and the answer says which happened: freshness.content.refresh is performed or declined-too-soon, never a cached answer presented as a fresh one.

Planned work

Accounts and the dashboard are being built out; until they land, sign-in answers with a service_unavailable envelope and anonymous publishing carries the whole flow. Changes to the terms or to plan limits are announced here before they take effect.

This page is about right now. What has already shipped, and when, is on the changelog.