> ## 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.

# Scrape Prometheus metrics

> Requires an authenticated employee session -- this exposes cross-tenant operational data (per-tenant job counts/durations, LLM token usage), gated by employee auth alone (a Prometheus scrape is not logged as a per-request user action, so it does not write an audit-log row). Computes gauges fresh from PostgreSQL on every scrape rather than accumulating in-process, so results stay correct across multiple API replicas: platform job counts/durations by type and status, tenant counts by lifecycle state, per-tenant ingest job counts, per-tenant LLM token usage this month, and pending job queue depth. A single tenant's metrics query failing is swallowed so it does not blank the whole scrape. Implemented in `services/api/metrics_api.py`.



## OpenAPI

````yaml /api-reference/openapi.json get /metrics
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:
  /metrics:
    get:
      tags:
        - Health & Observability
      summary: Scrape Prometheus metrics
      description: >-
        Requires an authenticated employee session -- this exposes cross-tenant
        operational data (per-tenant job counts/durations, LLM token usage),
        gated by employee auth alone (a Prometheus scrape is not logged as a
        per-request user action, so it does not write an audit-log row).
        Computes gauges fresh from PostgreSQL on every scrape rather than
        accumulating in-process, so results stay correct across multiple API
        replicas: platform job counts/durations by type and status, tenant
        counts by lifecycle state, per-tenant ingest job counts, per-tenant LLM
        token usage this month, and pending job queue depth. A single tenant's
        metrics query failing is swallowed so it does not blank the whole
        scrape. Implemented in `services/api/metrics_api.py`.
      operationId: metrics_metrics_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}

````