Skip to main content

alert.*

Alert webhook payloads contain the current alert and its timeline in data.events. Rootly emits alert.updated when the alert itself changes or a timeline event is added. Use the top-level event.id to deduplicate webhook delivery retries. Because the timeline is cumulative, use each data.events[].id to avoid reprocessing the same timeline entry across successive payloads. Events are ordered by created_at, oldest first. Adding a timeline event emits alert.updated; editing or deleting an existing timeline event does not.

Alert ownership changes

Manual ownership transfers preserve the existing kind: action and action: paged contract. They add page_reason: manual_reassignment so consumers can distinguish an explicit destination change from other pages. For multi-target pages, adding or removing a destination counts as an ownership change, and each successful page event from that request includes the reason. The same page_reason discriminator is available on alert events returned by the public API and mobile API.
Progression between levels of the current escalation policy does not include page_reason: manual_reassignment.
For a manual page, Rootly suppresses intermediate alert.updated deliveries and sends one update after the page operation settles. When the page creates a new alert, Rootly emits the normal alert.created event and also emits this settled alert.updated; subscribe to alert.updated for the resulting page event and ownership metadata. For a multi-target page, Rootly determines page_reason from the destinations that were successfully paged, and the cumulative timeline contains every successful page event from the request, including corrected metadata on earlier events when a later success changes the batch reason. Use the top-level event.id to deduplicate retries and each timeline event’s id to reconcile the cumulative data.events list. Ownership-change timeline events include:
  • user: The complete user associated with the event. For an action event this is the actor; for a notification event this is the recipient. user_id remains available for compatibility.
  • paged_user: For a user-group page that fans out to an individual on-call user, the complete recipient user. This keeps the selected group in notification_target while identifying who was actually paged. The field is omitted for other target types.
  • notification_target: On the manual-page event, the notification target originally selected by the actor. Supported manual-reassignment types are escalation_policy, group, service, functionality, and user.
group is the serialized target type for a Team selected in the Rootly interface. Every notification_target includes stable type and id fields. When the selected resource still exists, Rootly also includes its standard outgoing webhook fields: Downstream notification events can also identify the channel or space that received a notification. These are not manual-reassignment targets: If the referenced resource was deleted or is otherwise unavailable when the webhook is generated, notification_target remains present with only its stored type and id. Consumers should therefore treat all additional fields as optional. When an alert is transferred to an escalation policy with no pageable targets, the manual-page event still identifies the selected policy and the resulting alert.updated payload reports data.status as open. If the alert was previously non-open, the timeline also includes a kind: status_update event with action: open; an alert that was already open does not record another status transition.

alert.updated manual reassignment example

The following representative payload shows the output of Rootly’s outgoing alert serializer for a manual transfer to an escalation policy with no pageable targets. Optional fields may vary by alert and serializer version:
JSON

genius_workflow_run.*

JSON

incident.*

JSON
When custom fields on action items are enabled for your team, each action item in the action_items array carries a custom_field_selections array for the fields placed on its form. Each entry looks like:
JSON
Free-text, number, and date fields populate value; reference-type fields (user, team, service, catalog entity, environment, cause, incident type) populate the matching selected_* array instead.

incident_post_mortem.*

JSON

pulse.*

JSON