Status
The status page
https://search.k8s-dev.zaproo.net/status shows whether each part of Zaproo Search works right now. The answer is at most 15 seconds old; there is no history or incident log yet.
The page shows an overall state, which is the worst of the services, and one line per service:
| Service | What it covers |
|---|---|
| Search and autocomplete | The storefront search and suggest routes, and search from the REST API and MCP. |
| Indexing | Document uploads, deletes, full syncs, reindexing and suggestion rebuilds: the tasks that change an index. |
| Dashboard and API | Signing in, the dashboard, and the REST API for managing projects, keys, indices and profiles. |
| MCP | The MCP server AI agents connect to. |
Each service is in one of three states:
| State | Meaning |
|---|---|
operational | It works. |
degraded | It works, but slower than it should. For indexing: tasks wait longer than usual before they start. |
down | It does not work. Requests fail, or tasks wait until it is back. |
Status route
GET/v1/statusAnyoneThe same answer as the page, as JSON. It always answers 200; the body carries the state:
{
"status": "operational",
"services": [
{"name": "search", "state": "operational"},
{"name": "indexing", "state": "operational"},
{"name": "dashboard", "state": "operational"},
{"name": "mcp", "state": "operational"}
],
"checkedAt": "2026-10-16T12:00:00.000Z"
}
checkedAt is when the state was last checked. Calls within 15 seconds of each other get the same answer, and the route is rate limited per IP address.
curl -s https://api.zaproo-search.com/v1/status
Using it in your monitoring
- Alert on the service you depend on, not on the overall state. A storefront that only searches cares about
search; indexing beingdowndelays new documents but leaves search working with what is already indexed. - Check every minute and alert after two or three bad answers in a row, not on a single one.
- Your storefront should not call the route on each page view. Check from your monitoring, and let the storefront degrade on its own when a search request fails.
Infrastructure probes
GET /health and GET /ready sit at the root of the API, outside /v1. They are for the load balancer and the cluster that run Zaproo Search, and answer only {"status": ...}. /health answers 200 while the API process runs. /ready answers 503 when this API instance cannot serve search, so traffic goes to another one. Neither tells you whether your part of the service works; use /v1/status for that.