Skip to main content
Use a Phare outgoing webhook to send Uptime incidents to Flashduty On-call. Created, propagated, partially recovered, and recovered notifications for one Phare incident land on one Flashduty alert: it triggers when the incident is created and closes automatically when it recovers.

​
In Flashduty On-call

Create either a dedicated or shared Phare alert integration and copy its complete Push URL.

​
Configure Phare

A Phare webhook body is written by you from placeholders, so the template below is the one to paste. Flashduty parses exactly this template.
1

Create an outgoing webhook integration

  1. Sign in to Phare, go to Integrations, and create an Outgoing webhook
  2. Paste the complete Flashduty Push URL (including integration_key) into Callback URL
  3. The signing secret can stay auto-generated. Flashduty does not verify the signature
2

Set the payload template

Paste this JSON as the payload template. Set event to the event key of the alert rule, for example uptime.incident.created or uptime.incident.recovered:
Keep incident.id. Flashduty rejects requests without it because it could not match a later recovery. Phare also sends the event key in the X-Phare-Request-Event header. Flashduty reads that header first and falls back to the event field.
3

Create alert rules

In Alert rules, create one rule per event for this webhook integration:
  • Incident created (uptime.incident.created)
  • Incident propagated (requires smart incident merging in Phare)
  • Incident partially recovered (requires smart incident merging in Phare)
  • Incident recovered (uptime.incident.recovered)
The Incident recovered rule is required, otherwise the Flashduty alert never closes. Do not set a rate limit so strict that it suppresses the recovery notification.
4

Verify the lifecycle

Make a monitored target actually fail and confirm Flashduty receives an active alert, then restore the target and confirm the alert recovers. Phare’s documentation describes no test button for webhooks, so verify with a real event.

​
Alert Key

Flashduty uses incident.id as the Alert Key. Phare’s created, propagated, partially recovered, and recovered events all expose the same incident entity, and {{ incident.id }} is that incident’s number, so every notification for one incident gets the same Alert Key. Changes to the title, description, state, impact, or affected monitors do not change it.

​
Status and severity

The event type comes from the X-Phare-Request-Event header: Severity comes from incident.impact: An incident is created when a monitor check fails, so an unknown impact is treated as Critical. A recovery event keeps the severity that impact maps to and sets the status to recovered.

​
Troubleshooting

  • Flashduty returns an invalid-parameter error: confirm the template is valid JSON, incident.id is not empty, and the request carries X-Phare-Request-Event or an event field
  • The alert does not recover: confirm an Incident recovered rule exists and uses the same template
  • No notification arrives: check the request and response in Phare’s webhook logs. Phare retries a non-2xx response up to 4 times
  • You want certificate expiry events: those events carry no incident number, so this integration does not handle them
See Phare Outgoing Webhooks and Phare alert rules for the full placeholder and header reference.