Skip to main content
Alerts carry timing information that’s often more accurate than your incident’s own timeline. The moment a problem is first detected usually happens before anyone declares an incident. You can reference an alert’s timestamps in the workflow engine, so workflows can act on when an alert was received or resolved. This is especially useful if you don’t create incidents from every alert. When a responder attaches an alert to an incident after the fact, a workflow can backfill the incident’s timing from the alert, with no manual data entry needed.

Available variables

When an alert is in scope, you can reference these timestamps:
VariableWhat it represents
Alert → Received atWhen incident.io received the alert from its source
Alert → Resolved atWhen the alert resolved (only set once the alert is no longer firing)
Received at is the time incident.io ingested the alert, which is the closest signal we have to when the problem started. Resolved at is empty until the alert actually resolves, so guard workflows that use it with a condition like Alert → Resolved at is set.

Where you can use them

These variables are available anywhere an alert is in scope, including:
  • Workflows using the an alert is attached to an incident trigger, where both the alert and the incident it’s attached to are in scope.
  • Alert routes, where you can use them in conditions and expressions.

Example: set an incident timestamp from the alert

A common use is to set an incident timestamp like Impact started at from the alert’s received time. This keeps your duration metrics (such as time-to-resolution) accurate even when the incident was created manually, minutes or hours after the alert first fired. To build this workflow:
  1. Create a new workflow and choose the an alert is attached to an incident trigger.
  2. Add a condition so you only set the timestamp when it’s currently empty, for example Incident → Impact started at is not set. This stops the workflow from overwriting a value a responder set by hand.
  3. Add the Set an incident timestamp step.
  4. Choose Impact started at as the Timestamp to update.
  5. Set the Value to the Alert → Received at variable using the Use variable button.
  6. Save and set the workflow live.
Now, whenever an alert is attached to an incident that doesn’t yet have an impact start time, incident.io sets it from the alert automatically.
A workflow using the "an alert is attached to an incident" trigger to set the incident's Impact started at
timestamp from the Alert → Received at
variable