IT & Security package

Incident triage

Monitoring alerts open prioritised ITSM incidents automatically; repeat alerts are deduplicated and P1/P2 incidents page the on-call engineer with escalation.

Headless / APIIntermediate~15 min setupv1.0.0
Download .utpkg 15 KBHow to install

About this package

What it does

Incident triage turns monitoring alerts into correctly prioritised incidents without anyone watching a dashboard. Your monitoring or alerting tool posts each alert (service, summary, severity, source, host and a dedupe key) to the workflow's webhook or start API.

The workflow looks the service up in the Service owners table for its tier, assignment group, on-call contact and runbook, and checks the ITSM for an open incident with the same dedupe key; repeat alerts are added to that incident as a work note. New alerts go through the Incident priority decision table (impact from the tier, urgency from the severity) to get P1 to P4 with response and resolution targets, an SLA is set and the incident is opened in the ITSM.

P1 and P2 incidents create an Acknowledge incident task for the on-call engineer with a 15-minute due time and escalation to the incident manager; acknowledging records the assessment and bridge link on the ticket and tells the business owner. P3 and P4 incidents are assigned to the team queue and the run completes. Adapt the service list, the priority matrix and the ITSM paths.

Headless / API

Headless: your monitoring tool posts each alert to the inbound webhook or the start API. People only see the acknowledgement task for P1 and P2 incidents.

Another system starts it over REST or an inbound webhook. No UI is needed; people only appear where a decision needs a human.

The flow

Step by step

  1. 1

    Alert received

    Monitoring posts the service, summary, severity hint, source, host and dedupe key.

  2. 2

    Look up the service

    The Service owners table gives the tier, assignment group, on-call contact, runbook and business owner.

  3. 3

    Deduplicate

    If an incident with the same dedupe key is already open, the alert is added to it as a work note and the run ends.

  4. 4

    Prioritise and open the incident

    The Incident priority decision table sets P1 to P4 and the response and resolution targets; the run SLA is set and the incident is created in the ITSM.

  5. 5

    Page on-call for P1 / P2

    The on-call engineer acknowledges with an initial assessment and bridge link within 15 minutes, or the task escalates to the incident manager. The ticket is updated and the business owner emailed.

  6. 6

    Queue P3 / P4

    Lower priorities are assigned to the team queue with the runbook link and the run completes.

Incident triage — Monitoring posts an alert; repeated alerts are deduplicated, the service tier and severity set the priority, an incident is opened in the ITSM and P1/P2 incidents page the on-call engineer for acknowledgement. The same canvas you get in the designer after installing.

Forms

Inputs and task forms

The inputs a caller passes when it starts a run, and the forms people complete when the process needs a decision.

Start inputs

Incident triage

Passed by the calling system

Service * service · textService name as in the Service owners table, e.g. order-service
Summary * summary · textOne-line alert summary, e.g. "p95 latency above 2 s for 10 minutes"
Severity hint * severity_hint · select
criticalmajorminorwarning
Severity from the monitoring tool: critical, major, minor or warning
Source source · textMonitoring tool or rule that raised the alert
Host host · textHost, pod or instance the alert fired on
Dedupe key * dedupe_key · textStable key for the alert condition; alerts with the same key update one open incident
Details url details_url · urlhttps://…Link back to the alert or dashboard
Oncall user id oncall_user_id · textOptional: user id of the on-call engineer (from your paging rota); falls back to the default chosen on install

User Task

Acknowledge incident

Acknowledge {{priority}} {{incident_number}}: {{service}}

I am working on this * acknowledged · boolean
Initial assessment * initial_assessment · text
Bridge / call link bridge_link · text
AcknowledgeNot an incident

Headless

Call it from your systems

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"service":"order-service","summary":"Checkout error rate above 5% for 10 minutes","severity_hint":"major","source":"Prometheus alertmanager: OrderErrorRateHigh","host":"order-service-7c9f6d-2kq8x","dedupe_key":"order-service:error-rate","details_url":"https://monitoring.example.com/alerts/order-error-rate"}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input service=order-service --input summary="Checkout error rate above 5% for 10 minutes" --input severity_hint=major --input source="Prometheus alertmanager: OrderErrorRateHigh" … --wait

Inbound webhook

shell
usertasks webhooks create <workflow id>          # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
  -H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
  -d '{"service":"order-service","summary":"Checkout error rate above 5% for 10 minutes","severity_hint":"major","source":"Prometheus alertmanager: OrderErrorRateHigh","host":"order-service-7c9f6d-2kq8x","dedupe_key":"order-service:error-rate","details_url":"https://monitoring.example.com/alerts/order-error-rate"}'

What's included

8 assets, ready to adapt

TypeNameDetails
Email templateMajor incident noticeSent to the business owner of the service when a P1 or P2 incident is acknowledged.
Data tableService ownersBusiness services with their tier (1 = most critical), on-call contact, ITSM assignment group, runbook and business owner. Monitoring alerts are matched on the service name.
IntegrationIT service management
API referenceCreate incidentPOST /incidents — Open an incident with the calculated priority, the service and assignment group from the Service owners table.
API referenceFind open incidentGET /incidents — Open incidents with the same dedupe key, so repeated alerts update one incident instead of opening new ones.
API referenceUpdate incidentPATCH /incidents/{{incident_id}} — Change the state, assignment or work notes of an incident.
Decision tableIncident priority8 rules — Priority from impact (the service tier) and urgency (the monitoring severity). P1 and P2 page the on-call engineer; P3 and P4 go straight to the team queue. First matching rule wins.
WorkflowIncident triage24 steps — Monitoring posts an alert; repeated alerts are deduplicated, the service tier and severity set the priority, an incident is opened in the ITSM and P1/P2 incidents page the on-call engineer for acknowledgement.

Service owners · 6 sample rows

ServiceTierOn-call contactAssignment groupRunbook URLBusiness ownerBusiness owner email

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Inbound webhook — An inbound webhook created for the workflow, so other systems can start it.
  • Email (optional) — Email delivery configured for the instance (EMAIL_PROVIDER), used for notifications.

After installing

  1. IT service management integration: set the base URL of your ITSM API and an API token. The references expect GET /incidents?dedupe_key=, POST /incidents and PATCH /incidents/{id}; adjust paths, body fields and response models in Integrations.
  2. Assignees: pick the default on-call engineer (used when an alert does not pass oncall_user_id) and the incident manager who receives escalations.
  3. Edit the Service owners rows: every service your monitoring reports, its tier, assignment group, runbook and business owner email. Unknown services are treated as tier 3.
  4. Review the Incident priority matrix and the response / resolution targets against your incident policy.
  5. Webhook: create an inbound webhook for the Incident triage workflow and point your alerting tool at it, mapping its payload to service, summary, severity_hint, source, host and dedupe_key.
  6. Email (optional): configure EMAIL_PROVIDER so business owners receive the major incident notice.

Asked for on install

  • Integration “IT service management”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://itsm.example.com/api· optional

  • Workflow “Incident triage” assigneesRequired

    • User for step “Acknowledge incident”nodes.15.config.assignee_id
    • User for step “Acknowledge incident”nodes.15.config.escalation_user_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download incident-triage-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/incident-triage-1.0.0.utpkg
usertasks packages inspect incident-triage-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install incident-triage-1.0.0.utpkg --dry-run
usertasks packages install incident-triage-1.0.0.utpkg       # prompts for each requirement
usertasks packages install incident-triage-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete incident-triage -f values.yaml

Verify the download

File SHA-256
0e3aeca1aa5f02a406a43312fe5b0969f50d20f09987001cec8d9f984a97f4c8
Package checksum (what is signed)
sha256:9e5ebbc37e0a07e124aa0b12c1853312e23dc55c63f48c714a67e556ca1b8c57
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 incident-triage-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-26First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery