Readiness probe: the database is the ONLY hard dependency on the web tier.

DELIBERATELY DIVERGES from Runflow: Runflow's readiness returns 503 when Redis is disabled (its workers self-replace when they lose Redis). Patricia's Redis is OPTIONAL on the web path (the engine degrades to NullCacheService), so a Redis outage must NEVER 503 the web tier. Doing so would restart-loop the API during an ordinary Redis blip even though it can still serve traffic.

Redis and the TaskIQ broker are still reported in checks for observability, but ONLY a failing DB SELECT 1 sets the status code to 503. Worker liveness is handled separately by the worker heartbeat (tasks/broker.py), not by this endpoint.

checks.redis.status:

• connected: the published Redis manager answers a ping.
• degraded: the published Redis manager does not answer a ping.
• not_connected: API_REDIS_URL is set and no Redis manager is published. After a failed boot connect, the API retries in the background and publishes the manager once a ping succeeds, unless its recovery task stopped (redis_recovery_stopped in the API logs).
• disabled: API_REDIS_URL is not set and no Redis manager is published.

checks.broker.status:

• disabled: no TaskIQ broker is published. With API_REDIS_URL set, the API starts the broker after it publishes the Redis manager, so this can appear beside a connected Redis check.
• connected: a broker is published and the Redis check reads connected.
• degraded: a broker is published and the Redis check reads any other value.

A published broker takes its status from the Redis check. A Redis-backed broker uses its own connection pool, which this probe does not use, so connected does not prove that the broker can enqueue.

status is ok when the DB check passes, the Redis check reads connected, and a broker is published. Otherwise it is degraded. Without API_REDIS_URL the Redis check reads disabled, so status is degraded.

PREVIEW CARVE-OUT: in a preview the DB probe is not run and the endpoint cannot 503; see :func:_database_check. Consumers gating on checks.database.status must accept skipped alongside connected (preview-login.yml does).

checks.model_provider is reported for the same reason and goes one step further: it moves neither the status code NOR status, because the web tier serves its whole non-agent surface without a model key.

Manages its own DB session (not Depends(get_db)) so a DB outage surfaces as a 503 here instead of the get_db teardown turning it into a 500. A registered manager alone does not prove the connection is live, so we issue a real query.