Alerts and ingest

Sending an alert

Every alert is one HTTP POST to the team’s address. The credential is the team’s integration key, created under the team’s Integration keys tab in the console. It goes in the Authorization header as is, with no Bearer or other prefix. A key behind the wrong prefix is a 403, and a key in any other header is a 401.

curl -X POST https://api.igniteops.io/v1/organizations/{org}/incident-management/{team}/alerts \
  -H "Authorization: ign_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Database connection pool exhausted on prod-db-01",
    "message": "PgBouncer reports 100% pool utilisation for 5 minutes. API latency p99 is above 4 s.",
    "source": "datadog",
    "severity": "P1",
    "alias": "db-pool-exhausted",
    "entity": "prod-db-01",
    "alert_url": "https://app.datadoghq.com/monitors/12345",
    "tags": { "env": "production", "service": "postgres" },
    "custom_fields": { "runbook": "https://wiki.example.com/runbooks/pgbouncer" }
  }'

The answer is a 201 with the alert as stored. Two fields are worth reading: routing says whether the routing rules and the escalation policy were started (started) or whether the alert was stored without paging anyone (suppressed, with a routing_reason of quota_exceeded or team_disabled), and on the Free plan quota carries the month’s counter.

HTTP/1.1 201 Created
{
  "alert_id": "0f1d2c3b-4a5e-4f60-9b7c-8d9e0f1a2b3c",
  "title": "Database connection pool exhausted on prod-db-01",
  "severity": "P1",
  "status": "open",
  "source": "datadog",
  "alias": "db-pool-exhausted",
  "count": 1,
  "routing": "started",
  "quota": { "plan": "free", "used": 12, "limit": 100, "resets_at": "2026-12-01T00:00:00.000Z" },
  "href": "https://api.igniteops.io/v1/organizations/acme/incident-management/platform/alerts/0f1d2c3b-…",
  "created_at": "2026-11-08T03:07:11.412Z"
}

A signed-in person can create an alert too: the Create alert button in the console and in the mobile app, for any team of the organization, whatever their team role. Such an alert carries source: manual and is routed and escalated exactly like one from a webhook, which makes it the easiest way to exercise a new routing rule or policy.

The fields

Only title and message are required. Text longer than a field’s limit is clipped to it and the alert is still created: an alert from a monitoring tool must page someone even when its description is long.

Deduplication by alias

A monitor that fires every minute would create sixty alerts an hour and page the team sixty times. Send an alias with the alert, a stable name for the condition such as db-pool-exhausted or the monitor’s own id, and the repeats fold into one alert.

• A request whose alias matches an alert that is open or acknowledged is answered 200 with deduplicated: true. The alert’s count goes up by one and its last-occurrence time is updated. Nothing new is created, and the repeat never counts against the monthly quota.
• If that alert is open and no escalation is running for it any more (every step has fired, or the policy had no repeat), the repeat starts the routing again, so a problem that comes back after the team stopped being paged pages them again.
• An alias that only matches a closed alert creates a new alert. A closed alert never absorbs new occurrences.
• There is no time window. The alias is compared against the alerts of that team, whatever their age, until they are closed.

HTTP/1.1 200 OK
{
  "alert_id": "0f1d2c3b-4a5e-4f60-9b7c-8d9e0f1a2b3c",
  "deduplicated": true,
  "count": 2,
  "status": "open",
  "routing": "started"
}

app.igniteops.io/org/acme/alerts

Severity

Five levels, named in the console as Critical, High, Medium, Low and Info. The severity decides the wording of the notifications (the push title starts with 🚨 CRITICAL:, the SMS with IgniteOps CRITICAL:, and so on for the other levels), it is the most common field a routing rule matches on, and it can be changed on the alert afterwards from the Properties panel.

There is no separate priority field. A rule that tries to match priority or status is refused when it is saved.

The life of an alert

An alert is open, acknowledged or closed. There is no other state. Acknowledging stops the escalation and assigns the alert to the person who acknowledged it. Closing records that the problem is over. A closed alert can be reopened, and an acknowledged one can be unacknowledged, which reopens it and removes the assignee.

• Acknowledge, Unack, Close and Reopen each take an optional note of up to 2,000 characters, which goes on the timeline.
• Comments are Markdown (paragraphs, lists, code, links, tables), up to 5,000 characters, and can be edited and deleted.
• Properties: the source, the entity, the alias, the occurrence count, who acknowledged and closed it, the escalation that ran, the tags, the custom fields and the link to the tool.
• The timeline records every routing decision, every notification with its delivery status, every acknowledgement and where it came from, and every comment, filterable by kind.

Who may do what follows the team role: Owners, Managers and Responders acknowledge, close, comment and change an alert, Observers read. The roles page has the whole matrix. Through the API, PUT on the alert changes status, assignee, severity, tags, custom_fields and notes, with an optional expected_updated_at so two people editing at once cannot overwrite each other.

app.igniteops.io/org/acme/teams/platform/alerts/…

Ways to acknowledge

curl -X POST https://api.igniteops.io/v1/organizations/{org}/incident-management/{team}/alerts/{alertId}/ack \
  -H "Authorization: PAT <your personal API key>"

Quota and limits

On the Free plan a team may route 100 alerts a calendar month, counted in UTC. Beyond that, alerts are still stored and visible, the sender still gets a 201 with routing: suppressed and an X-IgniteOps-Quota header, and nobody is paged until the counter resets or the organization upgrades. The owner is emailed at 80% and at 100%. Repeats absorbed by an alias never count. Free organizations may also send at most 30 alerts a minute and 1,000 a day. Beyond that the API answers 429 with a Retry-After.

On Pro every alert is routed. The first 100 each month are included and each one after that is $0.10.

During a service disruption

An alert that arrives during a service disruption is still accepted and paged. Its answer carries degraded: true and no quota, and the alert appears in the list once the service recovers. Acknowledgements, updates and closes made during the disruption answer 503 with a Retry-After of 30 seconds and should be retried.

Metrics

The dashboard shows, for the organization and for each team: open and acknowledged alerts, the mean time to acknowledge (MTTA) and time to resolve (MTTR), the alerts by severity, the top sources and the busiest teams, all over the whole history. The numbers are recalculated in the background, so a brand-new organization sees them after the first run, and a figure older than an hour is flagged as stale.

On Pro, a weekly review is written from the same data: findings, what to do next, and the evidence tables behind them (this week against last, MTTA median and 90th percentile, MTTR median, the noisiest alerts, duplicate storms, escalation and on-call coverage, the backlog). Hourly insights point out patterns, anomalies and recommendations, and each can be dismissed for 30 days.

app.igniteops.io/org/acme/dashboard