> ## Documentation Index > Fetch the complete documentation index at: https://docs.timbal.ai/llms.txt > Use this file to discover all available pages before exploring further. # Alarms Health > For every enabled alarm, when the metric series behind it last produced a datapoint. Answers the one question an alarm's own `state` cannot: is it still watching anything? Under the default `not_breaching` policy an alarm whose metric stopped being emitted — a deleted workforce, a disabled trace filter, a renamed metric — sits at `ok` indefinitely and looks identical to one that is genuinely healthy. `stale` marks silence lasting ten evaluation windows (minimum one hour), which is long enough that a quiet-but-live series won't trip it. A brand-new alarm reads as stale until its first datapoint, which is accurate: it cannot fire yet. For a ratio alarm, `last_datapoint_at` is the **older** of the two series, since a period only yields a datapoint where both sides have one. A live numerator over a dead denominator is therefore reported as stale — every period resolves to a missing ratio, so the alarm is blind despite one of its series still flowing. `denominator_last_datapoint_at` tells you which side went quiet. Covers the same alarms `GET /orgs/{org_id}/alarms` returns for you, so `healthy` and `stale_count` describe your visible subset — a project-scoped caller gets their project's blind spots, not the org's. ## OpenAPI ````yaml GET /orgs/{org_id}/alarms/health openapi: 3.1.0 info: title: Timbal Platform API description: Public API documentation for the Timbal platform license: name: '' version: 2.0.0 servers: - url: https://api.timbal.ai description: Production - url: https://api.dev.timbal.ai description: Development security: [] tags: - name: ace description: Action Control Engine (ACE) operations - name: alarms description: Metric series and threshold alarms - name: analytics description: Org and project analytics - name: billing description: Subscriptions, usage, and payment-related operations - name: channels description: Delivery channels alarms notify through - name: content description: Re-sign stored content URLs - name: files description: File operations - name: iam description: IAM — actions, roles, users, and authorization introspection - name: k2 description: Knowledge Bases v2 operations - name: orgs description: Organization operations - name: projects description: Project operations - name: runs description: Execution operations - name: templates description: Public project template catalog - name: users description: Authenticated user profile paths: /orgs/{org_id}/alarms/health: get: tags: - alarms summary: Find alarms that stopped receiving data description: >- For every enabled alarm, when the metric series behind it last produced a datapoint. Answers the one question an alarm's own `state` cannot: is it still watching anything? Under the default `not_breaching` policy an alarm whose metric stopped being emitted — a deleted workforce, a disabled trace filter, a renamed metric — sits at `ok` indefinitely and looks identical to one that is genuinely healthy. `stale` marks silence lasting ten evaluation windows (minimum one hour), which is long enough that a quiet-but-live series won't trip it. A brand-new alarm reads as stale until its first datapoint, which is accurate: it cannot fire yet. For a ratio alarm, `last_datapoint_at` is the **older** of the two series, since a period only yields a datapoint where both sides have one. A live numerator over a dead denominator is therefore reported as stale — every period resolves to a missing ratio, so the alarm is blind despite one of its series still flowing. `denominator_last_datapoint_at` tells you which side went quiet. Covers the same alarms `GET /orgs/{org_id}/alarms` returns for you, so `healthy` and `stale_count` describe your visible subset — a project-scoped caller gets their project's blind spots, not the org's. operationId: get_org_alarms_health parameters: - name: org_id in: path required: true schema: type: string responses: '200': description: Per-alarm data health content: application/json: schema: $ref: '#/components/schemas/OrgAlarmsHealthResBody' '403': description: Forbidden content: application/json: schema: $ref: '#/components/schemas/ErrorMessage' security: - bearer_auth: [] components: schemas: OrgAlarmsHealthResBody: type: object title: OrgAlarmsHealthResponse description: Wrapper for **GET** `/orgs/{org_id}/alarms/health`. required: - healthy - stale_count - alarms properties: alarms: type: array items: $ref: '#/components/schemas/AlarmDataHealth' healthy: type: boolean description: '`false` when any enabled alarm is `stale`.' stale_count: type: integer format: int64 description: |- How many of `alarms` are stale, so a caller can alert on the count without walking the list. ErrorMessage: type: object required: - code - message properties: code: type: string description: Machine-readable error code (e.g. `ALREADY_EXISTS`, `BAD_REQUEST`). message: type: string description: Human-readable description. AlarmDataHealth: type: object description: >- An enabled alarm and when the series behind it last produced a datapoint. required: - id - name - metric_name - state - stale properties: denominator_last_datapoint_at: type: - string - 'null' format: date-time denominator_metric_name: type: - string - 'null' description: >- Set only for ratio alarms, so a caller can tell which side went quiet. id: type: integer format: int64 last_datapoint_at: type: - string - 'null' format: date-time description: >- When this alarm could last have evaluated a period. For a ratio alarm this is the *older* of the two series, because `ratio_datapoints` yields a datapoint only where both sides have one — reporting the numerator alone would call an alarm healthy while every period actually resolves to missing. `null` = no evaluable period within the metric retention horizon, which for a ratio alarm includes "one of the two series never reported". metric_name: type: string name: type: string stale: type: boolean description: >- The series has been silent long enough that the alarm is almost certainly watching something that no longer exists. Silence is counted from the alarm's creation when that is later than `last_datapoint_at`, so a freshly created alarm is not accused of being blind before it has had a chance to see anything. Same judgement `crate::alarms::staleness` notifies on. state: $ref: '#/components/schemas/AlarmState' AlarmState: type: string enum: - ok - alarm - insufficient_data securitySchemes: bearer_auth: type: http scheme: bearer description: >- Timbal API key. Obtain your API key from the Timbal platform settings. See [Authentication](/api-reference/authentication) for more information. ````