Page Responding Teams for Impacted Services/Functionalities

The Page Responding Teams for Impacted Services and Page Responding Teams for Impacted Functionalities Runbook steps allow you to automatically page the owning teams of any Services or Functionalities that are marked as impacted on an incident. Unlike the Page people via Signals step, no hardcoded targets are required. The step dynamically resolves the right teams at execution time using your Service Catalog.

Prerequisites

For these steps to page successfully, the following must be configured in your Service Catalog:

• Each service or functionality you want to trigger paging for must have a team set as a Responder.
• Each responding team must have a default Escalation Policy configured.

If either of these is missing for a given service or functionality, that component will be skipped when the step fires. Configuration

Configuration

1. When editing or creating a Runbook, click + Add Step and search for the FireHydrant dropdown. Select either Page Responding Teams for Impacted Services or Page Responding Teams for Impacted Functionalities, depending on which component type you want to drive paging.
2. Fill out the following fields:
   1. Name (required) — A descriptive name for the step, shown on the Runbooks tab for any incidents this Runbook attaches to.
   2. Alert Summary(required) — The summary/title of the alert that will be created. Defaults to the name of the incident.
   3. Alert Body — An optional description or body for the alert.
3. Click Save on the modal, then click Save Runbook at the top right to persist your changes.

When the step fires, FireHydrant looks up every service (or functionality) currently marked as impacted on the incident, resolves the responding team(s) for each from the Service Catalog, and pages their default Escalation Policy via Signals. A Signals alert is created for each team paged and automatically linked to the incident.

These steps are re-runnable by default. If additional services or functionalities are added as impacted mid-incident, you can re-run the step, and it will page the teams for any newly added components.

The incident Timeline will reflect each alert generated via this step.

Using Runbook Conditions with These Steps

Because these steps live in the Runbook system, they support the full range of Runbook conditions — including severity, incident type, milestones, tags, and more. This makes them well-suited for conditional, service-aware paging workflows that Auto-Alerting alone cannot support.

For example, you could configure a step to only page responding teams when an incident is declared at SEV1, while a SEV2 incident simply notifies a Slack channel instead.