In Flashduty On-call
You can get the integration Push URL in either of the following two ways.
Use a dedicated integration
- In the Flashduty console, select Channels and open a channel
- Select Settings → Integrations → Dedicated integrations, then click Add an integration
- Select Robotalp and click Save
- Open the generated integration card and copy the Push URL
Use a shared integration
- In the Flashduty console, select Integration Center → Alert Events
- Select Robotalp and enter an integration name
- Configure the default route and select a channel; you can add more rules under Routes after the integration is created
- Click Save and copy the generated Push URL
Configure Robotalp
1
Add a Custom Webhook integration
- Sign in to Robotalp, click the avatar in the top-right corner to open the account menu, and select Integrations
- Click Add Integration and select Custom Webhook
- Enter a name and set the URL to the complete Flashduty Push URL, including
integration_key - Save. No custom headers are needed
2
Enable the webhook on each monitor
- Edit the robot you want to watch (in the create or edit dialog) and open its Alerts tab
- Under Notification Preferences, turn on the webhook you just created
- If a notification frequency option is offered, only once until resolved is recommended (one notification when the monitor goes down, one when it recovers)
3
Verify
- Click Test Connection in the Add Integration or edit form. Flashduty creates an Info alert titled
Robotalp test notification. It never recovers, so close it by hand after checking - Temporarily change the monitor’s address to one that returns an error (for example HTTP 503) and wait for the next check; a Critical alert appears in Flashduty
- Change the address back and wait for the next check; the alert recovers
Alert Key
Flashduty uses
incident_id from the request body as the Alert Key. Robotalp sends the same incident_id on the down notification and the recovery notification of one downtime. We verified this on a real Robotalp account: a monitor went down and then recovered, and both deliveries carried the same incident_id.
- Changes to the monitor name, address, error message, or downtime duration do not change the Alert Key
- Two separate downtimes of the same monitor have different
incident_idvalues and become two alerts - Requests without
incident_idare rejected, because their recovery could not be matched reliably
Status and severity
The Robotalp request body has no severity field, only
status.
Any other value is rejected. A recovery carries
resolved_at and downtime_seconds; Flashduty stores them as labels together with the failure reason result_message.
Troubleshooting
- Flashduty receives nothing: confirm the webhook is enabled under the monitor’s Notification Preferences and that the Push URL is complete, including
integration_key - The alert does not recover: confirm Custom payload does not override
incident_idorstatus. If the monitor is paused or deleted, Robotalp sends no recovery, so close the alert by hand; you can also turn on auto-close in the channel as a fallback - The test alert stays open: the Test Connection delivery never recovers; close it by hand