--- title: "Agentic Atlas service status · Agentic Atlas" description: "How Agentic Atlas fails and what to do about each refusal, with the liveness and readiness probes that report the live state." canonical: "https://agentic-atlas.dev/status" last-updated: "2026-08-19" --- Availability and failure modes # Agentic Atlas service status This page is stated copy, not a live board. It says how this deployment fails, what each refusal means, and what to do about it. The live answer is a probe, and the two of them are the first thing below. ## Live state Two addresses, both JSON, both unauthenticated and unlimited. Ask them rather than this page: it is deployment copy and reads no database, which is why it still answers when the Catalog does not — and equally why it can tell you nothing about right now. - [Agentic Atlas liveness probe](https://agentic-atlas.dev/healthz) (JSON) — Answers `200` with `{"status": "ok"}` whenever the process is running. It touches no database and reads no Catalog, so it is the one address that still answers during the outage every other address is failing on. - [Agentic Atlas readiness probe](https://agentic-atlas.dev/readyz) (JSON) — Answers `200` when this deployment can serve, and `503` with the same body when it cannot. Every check is named individually — database, migrations, Catalog, pairing, Release, human surface, MCP — alongside the active Release version and its Catalog revision, so a failure says which half is wrong rather than only that something is. ## What Agentic Atlas refuses, and what to do about it Every way this deployment can refuse a call, in the terms you received it. Two of these are contracts rather than faults — a batch is refused whole, and a Release is replaced whole — and each is listed here with its recovery, because a refusal published without one reads as fragility even when it is the design working. ### 503 Service Unavailable Every page and every JSON operation The Catalog is unreachable, or no Release is active. The address you called is correct and the request was well formed — this deployment is between states or its database is unreachable. **Recovery.** Retry the same call; the address does not change. If it keeps failing, read /readyz to see which check is failing, and treat the whole origin as down rather than the operation as retired. ### 404 on a batch read, or `batch_not_atomic` `/api/cards`, `/api/compare`, and the transport's batch tools A batch is atomic: one id the active Release does not admit refuses the whole call, and no partial payload is returned. This is deliberate — a batch that mixed answered ids with item errors would hand back a payload whose gaps a caller has to notice. **Recovery.** The refusal names the id that spoiled the batch. Drop that id and re-batch the rest in one call; do not fall back to one call per id, which costs a request per id to learn what the refusal already told you. ### A changed `X-Catalog-Revision` Every response, pages and JSON alike A promotion happened between your two calls. A Release is replaced whole rather than amended in place, so the revision marker changes once and everything behind it changes with it — there is no partially-updated state to read and no overlap window in which both are served. **Recovery.** Re-read anything you are still holding, and carry the new marker forward. Two responses with the same marker describe the same Atlas; two with different markers may disagree, and comparing them is the one thing to avoid. ### `revision_changed` The MCP transport, when a call carries `expected_revision` You pinned a consultation to a Release and that Release was promoted away underneath it. The refusal is the point: the alternative is silently answering the second half of your question out of a different Atlas than the first half. **Recovery.** Start the consultation again from the marker the refusal carries. A call that does not need coherence across several reads can omit `expected_revision` entirely and never meet this refusal. ### 429 Too Many Requests The JSON API and `/ask` More than 300 requests in one minute from one address. The pages, the probes and the MCP transport are not limited at all. **Recovery.** Wait for the window named on the response and continue. Every response states the limit and the window, refusals and successes alike, so a client can pace itself without ever meeting this one. ## What this page does not claim Stated rather than implied by omission, on the rule the rest of this domain follows: an absence you can read is cheaper than one you have to infer from a page that never mentions it. - **No service level agreement (SLA).** Nothing here is sold, so nothing here is promised. Availability is best effort, and the probes above are the only claim this deployment makes about itself. - **No uptime history and no incident feed.** This publisher keeps no record of past availability and publishes no timeline of past incidents, so there is nothing to subscribe to and no percentage to quote. - **No third-party status page.** There is no external dashboard hosted off this domain. This page is served by the deployment it describes — so if it is unreachable, that is itself the answer, and the liveness probe above is the cheapest way to ask. - **No maintenance windows.** A new Release is promoted in one atomic swap, and the surfaces stay up across it. Nothing is ever taken down to publish. - **No notification when a Release changes.** Nothing calls you back. A client notices a promotion by reading the revision marker on any response, which is the mechanism the recoveries above are written around. ## If something here is wrong A surface that refuses a call it documents, or a refusal this page does not list, is a bug rather than a policy. [Contact the publisher](https://agentic-atlas.dev/contact). The contracts themselves live at [the API reference](https://agentic-atlas.dev/api-reference) and [the consultation contract](https://agentic-atlas.dev/consult.md), and [the developer index](https://agentic-atlas.dev/developers) names every other address this domain publishes.