Skip to main content

Events

The Events page (/orgs/:org/events) is an org-wide, chronological timeline of what happened to your checks and incidents — every member of the organization can see it, not just admins. Each row shows when the event happened, what it was, who (or what) triggered it, and a link to the related check or incident.

Event types​

The type filter narrows the timeline to the most common operational events:

TypeMeaning
check.createdA check was added
check.updatedA check's configuration changed
check.deletedA check was removed
incident.createdA new incident opened
incident.acknowledgedAn incident was acknowledged
incident.escalatedAn incident escalated to the next step
incident.resolvedAn incident resolved

The incident.escalated event raised by an escalation policy step records what was paged, with names captured when the step fired (a later rename does not change old rows): step_uid, step_position, repeat_index, policy_uid, policy_name, check_name, check_slug, and targets, a list (at most 20) of {type, uid, name} entries where type is integration, user, schedule (plus on_call_user_uid / on_call_user_name when resolved) or all_admins. Targets skipped by the step's severity are not listed. The Events page shows them as "Step 2 · Ops Slack, alice", integrations and schedules linked.

Leaving the filter on All Events shows the complete stream — every event type the organization records, including status page publications, membership and integration changes, and more — each with its own label and badge. The dropdown's seven entries are shortcuts for the day-to-day noise, not the full list of what can appear here.

Private-location agent rows (agent.connected / agent.disconnected) name the agent under the label — its name and private location, plus the reason it dropped (ping timeout, revoked, server shutdown or error) on a disconnect — and the Related column links the agent to Organization → Private locations.

Discovery scans record discovery.scan_started and discovery.scan_canceled (with the type and, for a scan run from a private location, the location), and discovery.chunk_refused when an agent refuses a chunk of a scan because the range is not allowed or discovery is off.

The Actor column names the user, integration, or system process that triggered the event — including a Slack, Discord, or phone acknowledgment, which has no dashboard user behind it.

How it differs from the audit log​

Events and the audit log are two views over the same underlying record, aimed at different audiences:

  • Events is for everyone in the organization, and is scoped to what you'd want to see day to day: checks and incidents, front and center, with a quick filter for the most common types.
  • The audit log (Organization → Audit) is the admin/owner-only security and configuration trail — sign-ins, membership, tokens, integrations, escalation policies, and every other configuration change — with richer filtering (actor, target, source IP) and the provenance fields (client IP, user agent) that only admins and owners are allowed to see.

Any event you see on either page ultimately comes from the same GET /api/v1/orgs/:org/events endpoint — see the audit log page for the full filtering reference.

Incident events​

An incident's own timeline (acknowledged, escalated, resolved, comments…) is the same event stream, scoped to that one incident — see Incident Management → Events for the incident-specific view and its "Get Incident Events" endpoint.