> ## Documentation Index
> Fetch the complete documentation index at: https://docs.causeloop.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Report readiness of dependencies

> No auth required. Checks, in order: PostgreSQL connectivity and recent heartbeats from the required workers (`product-worker` and `provisioner-worker` by default, configurable via `CAUSELOOP_REQUIRED_WORKERS`) advertising the job types the product depends on (`materialize_insights`, `send_email`, `train_tenant_model`, `provision_tenant`); object storage reachability; credential-encryption key configuration; email delivery provider configuration; and, if `REDIS_URL` is set (or required in production via `CAUSELOOP_REDIS_REQUIRED`), a Redis ping. Returns `{"status": "ready", "checks": {...}}` with HTTP 200 if every check passes, or `{"status": "not_ready", ...}` with HTTP 503 otherwise -- one boolean per check plus failure detail.



## OpenAPI

````yaml /api-reference/openapi.json get /health/ready
openapi: 3.1.0
info:
  title: CL MVP Product API
  description: >-
    The Causeloop MVP Product API is a deliberately small, explicitly
    allowlisted HTTP surface: `services/api/product_app.py` enumerates every one
    of the 44 published (method, path) operations drawn from seven routers, and
    only those operations are mounted onto this app -- everything else defined
    in the underlying routers (and the entire legacy research surface in
    `services/api/main.py`) is not exposed here. Staff (employee) and
    tenant-user sessions are separate cookie-based principals with no shared
    session table; mutating requests are protected by a double-submit CSRF
    cookie/header pair. See `/api-reference/authentication` for session and CSRF
    details, and `/api-reference/errors-and-conventions` for shared error shapes
    and status-code conventions.
  version: 1.0.0
servers: []
security: []
tags:
  - name: Auth
    description: >-
      Staff (employee) and tenant-user session lifecycle: login/logout,
      current-identity reads, invitation acceptance, and the public pre-login
      workspace directory.
  - name: Staff Onboarding
    description: >-
      The Onboarding Portal surface used to create, provision, ingest data for,
      train, activate, and go-live a tenant. Every operation requires an
      authenticated employee session; mutations additionally require the
      `onboarding_admin` control role (`support_readonly` employees can read but
      not write).
  - name: Insights
    description: >-
      Tenant-facing reads of materialized insight collections (themes, severity,
      issues, fishbone, and related model outputs) produced by the training and
      materialization pipeline.
  - name: Members
    description: Read-only tenant member directory.
  - name: Sources
    description: Tenant-facing source-connector registration and file-upload ingest.
  - name: Remediation
    description: >-
      Tenant-scoped corrective action plans (CAPs), human-in-the-loop issue
      reviews, the tenant audit trail, and the branded Excel export.
  - name: Health & Observability
    description: >-
      Unauthenticated liveness/readiness probes and the employee-only Prometheus
      metrics scrape endpoint.
paths:
  /health/ready:
    get:
      tags:
        - Health & Observability
      summary: Report readiness of dependencies
      description: >-
        No auth required. Checks, in order: PostgreSQL connectivity and recent
        heartbeats from the required workers (`product-worker` and
        `provisioner-worker` by default, configurable via
        `CAUSELOOP_REQUIRED_WORKERS`) advertising the job types the product
        depends on (`materialize_insights`, `send_email`, `train_tenant_model`,
        `provision_tenant`); object storage reachability; credential-encryption
        key configuration; email delivery provider configuration; and, if
        `REDIS_URL` is set (or required in production via
        `CAUSELOOP_REDIS_REQUIRED`), a Redis ping. Returns `{"status": "ready",
        "checks": {...}}` with HTTP 200 if every check passes, or `{"status":
        "not_ready", ...}` with HTTP 503 otherwise -- one boolean per check plus
        failure detail.
      operationId: readiness_health_ready_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                additionalProperties: true
                type: object
                title: Response Readiness Health Ready Get

````