Deduplicate and Prioritize Incident Alerts by Severity
Managing a flood of incident alerts from diverse sources can overwhelm IT teams. This workflow receives structured alerts via webhook, validates incoming data, groups alerts by service and error code, counts occurrences, determines the highest severity and most recent event per group, and calculates a priority value. The result is a consolidated, priority-sorted list of incidents in JSON format—ideal for teams seeking to efficiently summarize and prioritize large volumes of alerts.
IT teams and operators of monitoring or incident management systems benefit from this workflow when handling numerous alerts from various sources and aiming to consolidate them efficiently. Structured alerts are received as JSON via a POST webhook. The workflow checks that the input is a non-empty array of alerts containing the fields service, errorCode, severity (1-5), and timestamp. Invalid inputs are rejected with a clear error message and index. Valid alerts are grouped by service and error code, the count per group is calculated, and both the highest severity and most recent timestamp are identified. For each group, a priority is computed (maxSeverity*100 + count). The output is a list of incidents sorted by priority, including all relevant fields, returned as JSON. Webhook authentication must be enabled separately in n8n to prevent unauthorized access. Execution data is stored in n8n and should be managed according to data protection requirements. The workflow can serve as a foundation for further automations such as notifications or ticket creation. Adapting to custom alert schemas is possible but may require changes in the code node.
AI-generated image
Installation
1. Import the workflow into n8n.
2. Check the Webhook node and enable webhook authentication in n8n.
3. Save the workflow.
4. Start the test listener and copy the test URL shown in the Webhook node.
5. Use a tool like curl or Postman to send a POST request with Content-Type application/json and the example body below to the test URL:
```json
{
"alerts": [
{"service": "DB", "errorCode": "E1", "severity": 3, "timestamp": "2024-06-01T10:00:00Z"},
{"service": "DB", "errorCode": "E1", "severity": 5, "timestamp": "2024-06-01T11:00:00Z"},
{"service": "API", "errorCode": "E2", "severity": 2, "timestamp": "2024-06-01T09:00:00Z"}
]
}
```
6. Check the response (see usage notes). Only after a successful test, publish/activate the workflow and use the production URL from the Webhook node.
Usage
1. Send a POST request with Content-Type application/json and a body as described in the import guide to the webhook URL.
2. Expected success response (HTTP 200):
```json
{
"status": "success",
"incidents": [
{
"fingerprint": "DB|E1",
"service": "DB",
"errorCode": "E1",
"count": 2,
"maxSeverity": 5,
"latestTimestamp": "2024-06-01T11:00:00Z",
"priority": 502
},
{
"fingerprint": "API|E2",
"service": "API",
"errorCode": "E2",
"count": 1,
"maxSeverity": 2,
"latestTimestamp": "2024-06-01T09:00:00Z",
"priority": 201
}
],
"inputCount": 3,
"incidentCount": 2
}
```
3. Error case (e.g., missing field, HTTP 200):
```json
{
"status": "error",
"message": "alerts muss ein nicht-leeres Array sein."
}
```
Or for invalid alert:
```json
{
"status": "error",
"message": "Ungültiger Alert.",
"invalidIndex": 1
}
```
4. Actual outputs and errors are returned as JSON. Check the fields status, incidents, inputCount, and incidentCount.
5. Webhook authentication must be enabled separately in n8n. Use the production URL only after successful testing.
6. Execution data is stored in n8n. Configure retention and access rights as needed.
Required connections and APIs
API connections
No saved API credentials were detected in the workflow JSON. Still check webhooks, target systems, credentials, and data protection before activation.
Nodes
WebhookCodeRespond to Webhook
Isolated functional test passed
Optional isolated functional test
The isolated data flow was tested without external services or credentials.
✓ Standard case with complete dataChecks the complete standard flow with valid sample data.Isolated functional test passed✓ Variation or boundary caseChecks a valid variation or an important boundary case.Isolated functional test passed✓ Additional processing ruleChecks this workflow's additional business processing rule.Isolated functional test passed✓ Invalid or incomplete inputChecks that invalid or incomplete data is rejected safely.Isolated functional test passed✓ Empty inputChecks that an empty request receives a controlled response.Isolated functional test passed
