In Flashduty On-call
You can get the integration push URL in either of the following ways.
Use a dedicated integration
- In the Flashduty console, go to Channels and open a channel
- Select Configuration → Integrations → Private integration, then click Add an integration
- Select Simple Observability and click Save
- Open the new integration card and copy the push URL
Use a shared integration
- In the Flashduty console, go to Integration Center → Alert Events
- Select Simple Observability and enter an integration name
- Configure the default route and select a channel. You can add more rules under Routes after creation
- Click Save and copy the generated push URL
In Simple Observability
1
Add a webhook channel
- Log in to Simple Observability, open the Channels page, and click Add Channel
- Select Webhook as the channel type
- Paste the full Flashduty push URL into Webhook URL
- Save the channel
- Click Test on the channel to verify the URL. Flashduty returns success and does not create an alert
2
Attach the channel to your alerts
In the notification settings of your alert rules, servers, scheduled jobs, and endpoints, select the webhook channel you just created.
3
Verify the lifecycle
Trigger a real alert, for example by making an endpoint unreachable, and confirm that an active alert appears in Flashduty. Then restore the object and confirm that the alert recovers.
Payload
The webhook POSTs JSON, which Flashduty parses directly without a template.
event_type decides which kind of object the alert is about:
How the other fields appear in Flashduty:
Alert Key
Flashduty uses the object type plus the object ID as the Alert Key, for example
endpoint:<data.endpoint.id>. The trigger and recovery notifications for one rule, server, endpoint, or job land on the same alert. Different objects produce different alerts, and objects of different types never affect each other even if their IDs match. Changing the name, severity, description, or time does not change the Alert Key.
If the object ID is missing, Flashduty returns a parameter error, because the recovery cannot be reliably matched to its alert. An event_type or status outside the table above is rejected as well.
The Simple Observability documentation shows only the trigger example for each type and does not state that the recovery notification carries the same object ID. Flashduty matches trigger and recovery by the data structure shared within each type. If an alert does not close after recovery, contact us and include the recovery request body.
Status and severity
Rule and job alerts carry a null
severity, so they are treated as Warning. A recovery notification (RESOLVED, SERVER_UP, ENDPOINT_UP, SUCCESS) closes the alert with the same Alert Key.
FAQ
Is a notification sent for every successful job run?
Is a notification sent for every successful job run?
That depends on your notification settings in Simple Observability. A
JOB_ALERT with SUCCESS is treated as a recovery: if the job failed earlier, the original alert is closed. If you do not want success notifications, turn them off for the job in Simple Observability.Does the channel test create an alert?
Does the channel test create an alert?
No. The test request has
event_type set to TEST. Flashduty returns success without creating an alert.What if one rule matches several hosts?
What if one rule matches several hosts?
A rule alert produces one Flashduty alert per rule ID. The matching hosts and values are shown on the alert detail page in Simple Observability, which you can reach through the
dashboard_url label.Troubleshooting
- Simple Observability reports an error: confirm the webhook URL is the full push URL and includes
integration_key - Flashduty returns a parameter error: the message names the missing object ID or the unsupported
event_typeorstatus - An alert does not recover: confirm the recovery is sent through the same webhook channel and that its object ID matches the trigger