---
title: "Readiness"
method: GET
path: "/v1/readiness"
tags: ["health"]
---

# Readiness

`GET /v1/readiness`

## Request

- Base URL: `https://api.patricia.app` (the document declares no server; this is the origin it was published from)
- URL: `https://api.patricia.app/v1/readiness`
- Auth: none declared

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.

## Response `200`

Successful Response

- object

---

[API](https://skmtc.dev/patricia/apis/patricia-api.md) · [All operations](https://skmtc.dev/patricia/apis/patricia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/patricia/apis/patricia-api/revisions/0dfb44495ea1?raw)