---
title: "Get list of alarm rules"
method: GET
path: "/v1/enterprise/{enterprise_id}/alarmrules/"
tags: ["esper_cloud_api_Alarms"]
---

# Get list of alarm rules

`GET /v1/enterprise/{enterprise_id}/alarmrules/`

⚠️ Android only. 

Returns a paginated list of all alarm rules configured in the enterprise. Alarm rules define the conditions under which device or fleet alerts are triggered — specifying which metric to monitor, the threshold conditions, which devices or groups are in scope, and which alert channels receive notifications when the rule fires.

**Key Query parameters**

name (optional) — Filter rules by name

description (optional) — Filter rules by description

is_active (optional) — Filter by active (true) or inactive (false) rules


**Response fields of note**

id — UUID identifying the alarm rule; used in all subsequent rule operations

name / description — Display name and description for the rule

metric — The device metric being monitored (e.g., battery level, connectivity)

conditions — Threshold definition including value, unit, comparator, and toggle_state

devices / groups — The specific devices or device groups the rule applies to

alert_channels — Array of alert channel IDs that receive notifications when the rule fires

action_emails — Direct email recipients for notifications, independent of alert channels

is_active — Whether the rule is currently enabled

realert_interval — Interval in minutes before the rule re-alerts if the condition persists

repeat_times — Number of times the alert will repeat

trigger_count / daily_trigger_count — Cumulative and daily counts of how many times the rule has fired

**Common use cases**

Auditing all active alarm rules across the enterprise to review monitoring coverage

Retrieving rule IDs for use in get, update, patch, or delete operations

Filtering for inactive rules to identify stale or disabled monitoring configurations

Reviewing trigger counts to assess alert frequency and rule health

**Best practices**

Use is_active=true to scope results to currently enabled rules when auditing live monitoring configuration

Use created_on_gt / created_on_lt to scope results to a specific time window when reviewing recently added or historical rules

Note that alarm_id used in single-rule operations is a UUID, unlike the integer alert_id used by alert channels

## Path parameters

- `enterprise_id` string, required

## Query parameters

- `name` string
- `description` string
- `is_active` boolean
- `created_on_gt` string
- `created_on_lt` string
- `limit` integer
- `offset` integer

## Response `200`

successful operation

- object
  - `count` integer, required
  - `next` string, url, nullable
  - `previous` string, url, nullable
  - `results` EsperCloudApiAlarmRule[], required
    - `id` string, uuid
    - `enterprise` string, uuid
    - `devices` object
      - `id` string, uuid
      - `device_name` string
      - `alias_name` string, nullable
    - `groups` string[]
    - `name` string
    - `description` string
    - `metric` string
    - `conditions` object
      - `value` number, double
      - `unit` string
      - `comparator` string
      - `toggle_state` boolean
    - `action_emails` string[]
    - `actions` string[]
    - `alert_channels` string[]
    - `created_on` string, date-time
    - `updated_on` string, date-time
    - `is_active` boolean
    - `realert_interval` integer
    - `repeat_times` integer
    - `trigger_count` integer
    - `daily_trigger_count` integer

## Other responses

- `401` — Authorization information is missing or invalid.
- `404` — Not Found.
- `500` — Internal server error

---

[API](https://skmtc.net/esper/apis/esper-api-reference.md) · [All operations](https://skmtc.net/esper/apis/esper-api-reference/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/esper/esper-api-reference/versions/e1f64cbb488e/schema)