docs

AlertOps

Receive AlertOps alerts in Plural

An AlertOps webhook delivers alerts from an AlertOps outbound integration into Plural. You define the request body in AlertOps, so you choose which fields Plural receives. Plural reads the Standard Alert template fields, plus keys that associate the alert with Plural resources. Each request is one alert, keyed by the AlertOps incident ID, so later requests for the same incident update it.

An alert does not start a job by itself. A job starts only when a webhook trigger on a workbench matches the alert, and only when the alert starts firing: the first firing request for an incident, or a firing request for one that had resolved. Updates to an incident that is still firing do not start another job, and an incident starts at most one job per workbench per hour.

What Plural reads from the payload

json
{
  "IncidentId": "<IncidentId>",
  "IncidentSubject": "<IncidentSubject>",
  "IncidentStatus": "<IncidentStatus>",
  "IncidentSeverity": "<IncidentSeverity>",
  "IncidentURL": "<IncidentURL>",
  "IncidentShortText": "<IncidentShortText>",
  "IncidentLongText": "<IncidentLongText>",
  "plrl_project": "payments",
  "plrl_cluster": "prod-us-east",
  "plrl_service": "checkout"
}
  • IncidentId identifies the alert. Requests without it all update one shared alert.
  • IncidentSubject becomes the alert title, and IncidentURL the link back to AlertOps.
  • IncidentLongText becomes the alert summary, falling back to IncidentShortText and then IncidentSubject.
  • IncidentStatus sets the state. OK, CLOSE, CLOSED, and RESOLVED, in any case, are resolved. Everything else is firing.
  • IncidentSeverity sets the severity, in any case:
Severity
AlertOps values
CriticalCRITICAL, SEV1
HighMAJOR, HIGH, SEV2
MediumWARNING, MEDIUM, SEV3
LowMINOR, LOW, INFO, SEV4, SEV5

Any other value leaves the severity undefined. An optional tags object with string values is stored as tags.

Associate alerts with Plural resources

Plural keeps an alert only when it belongs to a Plural project, cluster, or service, or when a workbench trigger matches it. Otherwise the request is acknowledged and ignored. Add these top-level keys to the body:

  • plrl_project: the project name.
  • plrl_cluster: the cluster handle.
  • plrl_service: the service name on that cluster. It only applies together with plrl_cluster.