Bu sayfanın Türkçesi de var. Türkçe oku → Close

Alert rules

An alert rule belongs to a project and decides which events go to which notification channels. If no channel is selected, all of the organization's active channels are used.

Log alerts

A log alert watches the number of logs matching a condition in the last N minutes. The condition speaks the same language as log search: if you put what you search for in the dashboard into the rule, you get the same result.

curl -X POST https://api.errorbird.com/api/v1/alert-rules \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "projectId": "<project-id>", "sourceType": "Log", "name": "Payment timeouts",
        "condition": { "logQuery": "timeout", "logMinLevel": "Error",
                       "logEnvironment": "production",
                       "logThreshold": 20, "logWindowMinutes": 5 } }'

Log silence

A rule with logBelowThreshold: true and logThreshold: 1 fires when no logs at all arrive during the window. This catches an application that crashed without throwing, a stalled queue consumer or a server that stopped sending logs; an error alert cannot see these, because there is no error.

How rules are evaluated

• Rules are evaluated once a minute. The window ends 30 seconds before now: logs are written with a few seconds of delay, and that delay must not look like silence.
• An alert is sent only when the state changes: once when it fires, and a "resolved" notification when the condition no longer holds. Even if the condition lasts for hours, you do not get a warning every minute.
• Counting stops at the threshold: "is it at least the threshold?" is enough for the decision, so millions of rows are not counted in a busy project. In the dashboard, a count equal to the threshold is shown as "≥ threshold".
• If the rule's condition changes, its triggered state is reset; the next evaluation decides based on the new condition.

Trying a rule before saving it

Guessing the threshold turns a rule into an alert that either never fires or fires all the time. In the dashboard, the Try with current logs button runs the rule against real logs without saving it:

curl -X POST https://api.errorbird.com/api/v1/projects/<project-id>/log-alert-preview \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "logQuery": "timeout", "logMinLevel": "Error", "logThreshold": 20, "logWindowMinutes": 5 }'
# { "count": 20, "countIsCapped": true, "wouldTrigger": true, "from": "…", "to": "…" }

Log alerts do not count as service outages: if the channel has quiet hours, they are sent when the window ends.

Escalation

If nobody acknowledges an outage alert, an escalation policy notifies other channels in turn: the team lead after 10 minutes if the on-call person did not wake up, and everyone after 30 minutes if the lead did not see it either.

curl -X POST https://api.errorbird.com/api/v1/escalation-policies \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "organizationId": "<org-id>", "name": "Night on-call",
        "steps": [ { "delayMinutes": 10, "channelIds": ["<lead-channel>"] },
                   { "delayMinutes": 30, "channelIds": ["<team-channel>"] } ] }'

The policy is attached to a monitor rule (escalationPolicyId). The first alert goes to the rule's own channels; the steps are added on top. At most 5 steps; delays are in minutes from the alert and must increase.

If a step should go to whoever is on call that week, put an on-call schedule channel in it. If you use PagerDuty or Opsgenie, you can also leave escalation to them: these channels open an incident at an outage, and the on-call schedule runs by the platform's own rules (see Notification channels).

Acknowledging

Alerts with a policy carry an acknowledgement link. The link opens a confirmation page; pressing the button acknowledges the incident and the pending steps are not sent. Opening the link alone does not acknowledge: messaging apps and email scanners open links in advance, so the action sits behind the button.

The incident row on the monitor page in the dashboard also has an Acknowledge button; there, the name of the person acknowledging is recorded.

curl -X POST https://api.errorbird.com/api/v1/incidents/<incident-id>/acknowledge \
  -H "Authorization: Bearer <token>"

• When a step is due, it is not sent if the incident has recovered or been acknowledged.
• The recovery notification goes to everyone notified by escalation: a team lead woken up at night should also learn that it recovered.
• Because outage alerts are urgent, steps ignore quiet hours (unless the channel has "hold outages too" selected).
• Pending steps are kept in Redis; they are not lost if the worker restarts.

On-call schedules

An on-call schedule answers "who is on call this week". Team members take turns in shifts of a fixed length; overrides cover leave and swaps. A schedule does not send notifications by itself: it is attached to an On-call schedule notification channel, and alerts sent to that channel reach whoever is on call at that moment by email and mobile push. You do not need to edit the channel or the alert rule when the on-call person changes.

curl -X POST https://api.errorbird.com/api/v1/on-call-schedules \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "organizationId": "<org-id>", "name": "Infrastructure on-call",
        "timeZone": "Europe/London", "rotationHours": 168,
        "startsAt": "2026-10-12T09:00:00+01:00",
        "participants": ["<alice-user-id>", "<bob-user-id>", "<carol-user-id>"] }'

curl -X POST https://api.errorbird.com/api/v1/notification-channels \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "organizationId": "<org-id>", "type": "OnCall", "name": "On-call",
        "scheduleId": "<schedule-id>" }'

• Shifts: rotationHours is 1–720 hours; 24 is a daily and 168 a weekly handoff. Shifts that are whole days advance in local time in the schedule's time zone: a "Monday 09:00" handoff stays at 09:00 across daylight saving changes. Shifts that are not whole days, such as 12 hours, advance by a fixed duration.
• Order: the order of participants is the rotation order; the first person starts at startsAt. Only members of the organization can be added. Someone removed from the organization drops out of the rotation and its overrides automatically; someone whose account is inactive is skipped and the next person takes the shift, so alerts are not lost.
• Usage: add the on-call channel to an alert rule or an escalation step like any other channel. A typical setup: rule → on-call channel; if not acknowledged within 10 minutes → team lead; after 30 minutes → team channel.
• Quiet hours can be set on the on-call channel too; a deferred notification goes to whoever is on call when it is sent.

Overrides

Someone else takes the shift for a given range (leave, sick day, swap). When the range ends, the rotation resumes. When overrides overlap, the latest one wins. A single override lasts at most 30 days and cannot be added for a range that has already passed. Members can add and delete overrides; setting up and changing the schedule is an admin task.

curl -X POST https://api.errorbird.com/api/v1/on-call-schedules/<schedule-id>/overrides \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{ "userId": "<carol-user-id>", "startsAt": "2026-10-14T09:00:00+01:00",
        "endsAt": "2026-10-16T09:00:00+01:00" }'

Who is on call and when the next handoff is

curl https://api.errorbird.com/api/v1/on-call-schedules/<schedule-id> \
  -H "Authorization: Bearer <token>"
# { "name": "Infrastructure on-call", "current": { "fullName": "Alice Smith",
#   "overrideId": null, "shiftEndsAt": "2026-10-19T08:00:00+00:00" }, … }

curl "https://api.errorbird.com/api/v1/on-call-schedules/<schedule-id>/shifts?from=2026-10-12T00:00:00Z&to=2026-10-26T00:00:00Z" \
  -H "Authorization: Bearer <token>"
# { "shifts": [ { "fullName": "Alice Smith", "startsAt": "…", "endsAt": "…", "overrideId": null }, … ],
#   "overrides": [ … ] }

The timeline includes overrides (by default the next 14 days, at most 62 days). In the dashboard, the On-call page shows who is on call now, the next handoff and a 14-day timeline. A schedule used by an on-call channel cannot be deleted; delete the channel or point it at another schedule first.