Basic Usage



  • An alert should represent an actionable issue that needs user interaction.
  • Alerts will notify users using the alert workflow.
  • Alerts are created by Integrations or Account Users
  • Alerts have one or more "destinations". An alert destination can be a Team, Account User, or Router.

User Interface

Alert UI Annotated

Annotation #Alert PropertyDescription
1Incident BannerIf the alert is an incident, will show severity and special message.
2Statusqueued|open|acknowledged|resolved|dropped - The current state of the alert. See alert states
3Response TimeThe difference between when the alert was first created and when it was first acknowledged (does not reset on a handoff)
4Alert SourceIntegration or Account user that created the alert.
5DestinationsTeams and Routers the alert was sent to.
6RespondersUsers that have acknowledged this alert.
7TitleShould be concise and descriptive. It shows up on all notification channels
8Public UrlThe public shareable URL to this alert (default: disabled)
9Urgencylow|medium|high|critical - Determines the push notification priority and can affect routers and notification rules.
10StakeholdersAny stakeholders that are attached to the alert
11Third Party IDThe unique identifier that maps this alert with and object in a 3rd party system
12Deduplication CountAn incrementing integer. Will increase if the Integration tries to create an alert with the same Third Party ID, another alert is created with the same
13TagsAny tags that are attached to the alert. Alerts can then be searched by the tags on the alerts page.
14Additional DataIf created by an integration, additional data that was extracted by the integration.
15Source LogIf created by an integration, the source log that created this alert.


Account users can comment on the alert. Comments are meant for human conversation.

Alert Comments


Alert logs are created by PagerTree to document what happened during the alert's lifecycle.

Alert Logs

Alert Actions


Acknowledging an alert indicates that the person acknowledging the alert will be responsible for addressing the alert. If the person is not able to adequately resolve the issue themselves, it is their responsibility to gather others who can help take this alert to resolution. The acknowledging user could also handoff the alert to another Account User or Team who could better address the alert.

To acknowledge an alert the alert must be in the open status.

Methods to Acknowledge

mobile appTap the push notification. On the alert page, click the acknowledge button.
emailClick the acknowledge button.
smsReply A.
voicePush 1.
slackClick the acknowledge button.
web uiClick the acknowledge button.

Methods to Reject


Rejecting an alert indicates that the person rejecting the alert cannot address the alert at the current time. (ex: The rejecting user is stuck in traffic.)

To reject an alert the account user must have an open workflow.

mobile appTap the push notification. On the alert page, click the reject button.
emailClick the reject button.
smsReply R.
voicePush 2.
slackClick the reject button.
web uiClick the reject button.


Resolving an alert indicates that the alert has been fully fixed (aka "resolved").

To resolve an alert it must be in the acknowledged state. Resolving an alert can only be done via the mobile app and web ui.

Integrations can auto-resolve alerts. In this case the an alert can go from open -> resolved directly.

Methods to Resolve

mobile appTap the push notification. On the alert page, click the resolve button.
web uiClick the resolve button.


You many handoff the alert to another Team or Router once the alert is in the acknowledged state. Handing off an alert can only be done via the mobile app and web ui.

Methods to Handoff

  1. In the top right of the alert page, Click Handoff.
  2. On the Alert Handoff form:
    1. Select a new destination for the alert.
    2. Provide a brief note as to why you are handing it off.
  3. Click Handoff.


Marking an alert as an incident communicates to your team members this alert is a greater degree of severity than a normal alert. It can be causing an outage or even customer facing. An incident represents a problem or an issue that needs to be addressed an resolved immediately.

  • Severity - Communicates the impact of an incident (see below).
  • Incident Message - A short message to be displayed at the top of the alert page (ex: "Please join the war room")

Alert Incident Banner


The incident severity level communicates the impact of the incident. It will be displayed on notification channels and in a red banner on top of the alert page.

If you are unsure which level an incident is (e.g. not sure if SEV-2 or SEV-1), treat it as the higher one (SEV-1).

SEV-1 (highest)Critical issue that warrants public notification and liaison with executive teams.
SEV-2Critical system issue actively impacting many customers' ability to use the product.
SEV-3Stability or minor customer-impacting issues that require immediate attention from service owners.
SEV-4Minor issues requiring action, but not affecting customer ability to use the product.
SEV-5 (lowest)Cosmetic issues or bugs, not affecting customer ability to use the product.
SEV-UNKNOWNImpact currently unknown (can be updated in the future)

Alert States

queuedInitial state of an alert. At this point, the alert has not been routed to any destinations.
openThe alert has been routed to its first destination. It has an open workflow and waiting to be actively acknowledged.
acknowledgedThe alert has been acknowledged by all destinations.
resolvedThe alert has been marked as resolved by a user or integration.
droppedThe alert was dropped because there was no one on-call or the users that were on-call did not acknowledge the alert.

Alert State


Who can create an Alert?Any account user or integration may create an alert.
What does the urgency mean / do ?The alert urgency determines the push notification priority and can affect routers and notification rules.
Common UI Design Patterns