---
title: "Readyz"
method: GET
path: "/readyz"
tags: ["ops"]
---

# Readyz

`GET /readyz`

## Request

- Base URL: `https://api.intura.co` (the document declares no server; this is the origin it was published from)
- URL: `https://api.intura.co/readyz`
- Auth: none declared

Readiness. Reports per-module load state, so a container that answers
/health but cannot actually serve inference is visible as such.

Readiness means "this module can answer", not "this module is at full
strength". Every module keeps serving without its artifact — the PII
detector on regex, the injection guardrail on phrases, the fraud screeners
on their lexical layers, the commerce classifier by escalating everything,
the document gates on geometry and optics — and failing readiness for that
would take every endpoint down on a box where one build was simply never
published. So a degraded module is reported, loudly, in `degraded[]` while
the probe still passes.

Watch that list, not just the status code. A few entries are expected in it
today, because labs has published no build for them: `routing/language`, and
both `documents/` gates wherever the shared OCR bundle is not installed.
That is the declared state, not a fault. Every text endpoint has had a
trained Indonesian model since 2026-09-21, so any of them appearing here is
worth alerting on — an injection guardrail or a PII detector that lost its
trained build is a security control that is nominally up and practically
weaker.

The two document gates degrade differently from the rest and it is worth
knowing how: without the reading bundle they cannot return `accept` at all,
so an onboarding flow in front of them stops accepting uploads rather than
accepting bad ones. That is the safe direction, and it is still an outage
for whoever is onboarding.

The `database` block is the exception to all of that — see the comment on it
below. It also carries the pool's live size and in-use count, which is the
number to look at when authenticated calls start timing out for no visible
reason: a saturated pool is latency everywhere and an error nowhere.

`document_reading` is the same kind of number for the other shared pool in
this process: the OCR readers both `documents/` gates check out per call.
`built` at `capacity` with `idle` at zero means uploads are queueing behind
each other inside the worker, which looks like latency on those two
endpoints and nothing at all anywhere else. Raise `OCR_POOL_SIZE` — with
`MAX_WORKER_CONCURRENT_INFERENCE`, never past it — or add a worker. Like
database saturation it does not fail the probe, and for the same reason:
it is a load signal, not a broken deployment.

## Response `200`

Successful Response

- unknown

---

[API](https://skmtc.dev/intura/apis/intura-ai-api.md) - [All operations](https://skmtc.dev/intura/apis/intura-ai-api/llms.txt) - [OpenAPI document](https://skmtc.dev/intura/apis/intura-ai-api/revisions/7cb6af4c6390?raw)