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

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Phare, then click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Phare and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Phare

1

Create an outgoing webhook integration in Phare

Where: Phare › Integrations › Outgoing webhook
2

Set the payload template in Phare

Where: Phare › Alert rules (the rule’s webhook payload; Phare generates a default JSON for the selected event; replace it with the template below)A Phare webhook body is written by you from placeholders, and Flashduty parses exactly the template below. Paste it as the payload template and 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 Phare

Where: Phare › Alert rulesCreate 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

Where: Phare › Integrations (view the webhook’s delivery logs)Phare’s documentation describes no test button for webhooks, so verify with a real event: make a monitored target actually fail and confirm Flashduty receives an active alert, then restore the target and confirm the alert recovers. The delivery logs show each request and response.

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.

Labels

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.