Skip to main content
Use an Instatus webhook subscriber to send changes on a status page to Flashduty On-call. A Flashduty alert triggers when the status page publishes an incident or a component goes into an outage state, and recovers when the incident becomes RESOLVED or the component returns to OPERATIONAL. Scheduled maintenance does not create alerts.

​
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, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Instatus and click Save
  4. Open the new integration card and copy the push URL

​
Use a shared integration

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

​
Add a webhook subscriber in Instatus

1

Open the webhook subscribers

Log in to Instatus, choose the status page, go to Subscribers, and open the Webhook tab.
2

Add the subscriber

  1. Click Add webhook subscriber
  2. Webhook URL: paste the full Flashduty push URL, including integration_key
  3. Email address: enter a team email address. Instatus emails this address when the URL has a problem
  4. Save. You can then click the subscriber to give it a name
Keep the default Instatus payload format and do not customize the request body for this subscriber: Flashduty parses the default format. The Webhook Secret in the form signs the x-instatus-webhook-signature request header; Flashduty does not verify the signature, so the default is fine. The integration_key in the push URL identifies the integration, so keep the URL private.One integration can follow several status pages. Alerts from different pages are told apart by page ID and never merge or close each other.
3

Verify

Saving the subscriber sends a validation delivery right away (the RUN button next to the Webhook URL field sends another). Flashduty recognizes it and answers with success, no alert.To verify with a real incident instead:
  1. In Instatus, go to Incidents and click Add incident. Set the status to Investigating, select an affected component, set it to Major outage, then save and notify subscribers. Flashduty shows an incident alert and a component alert, both Critical
  2. Add an update to that incident with the status Resolved, set the component back to Operational, and notify subscribers. Both alerts recover
If you publish an incident or update without notifying subscribers, Instatus sends nothing and Flashduty receives nothing.

​
Payload

Instatus sends one JSON payload each time an incident is added or updated, a component changes status, or a maintenance is added or updated. Flashduty handles the first two: Incident added or updated Component status change Component alert titles look like Website: major outage. Every alert also carries the label source=instatus, plus page_url and page_status. The unsubscribe link in the payload (meta.unsubscribe) contains a subscription credential, so Flashduty does not write it to the alert.

​
Alert Key

Flashduty builds the Alert Key per payload kind:
  • Incident: status page ID + incident ID. Every update of one Instatus incident, from INVESTIGATING to RESOLVED, lands on the same alert
  • Component: status page ID + component ID. Every status change of one component, from outage to recovery, lands on the same alert
Incident alerts and component alerts are independent. One outage usually produces both; use the channel’s alert grouping to group them into one Flashduty incident. Renaming an incident or component, or changing the impact, does not change the Alert Key. When the severity rises (for example a component going from PARTIALOUTAGE to MAJOROUTAGE), Flashduty opens a new alert at the higher severity and keeps the earlier alert open; the recovery delivery closes both. After an alert recovers, a new outage of the same component opens a new alert.

​
Status and severity

Component status Instatus incidents The alert severity is the worst status across the incident’s affected_components (same values as component status, only differently cased and spaced, e.g. Major outage), and the alert status comes from the incident status (status): An incident with no affected component falls back to the same mapping applied to impact instead — but on a dashboard-created incident, impact is usually just the status wording (e.g. Investigating), which matches none of these values and lands on Warning. Scheduled maintenance (maintenance payloads with the status NOTSTARTEDYET, INPROGRESS, or COMPLETED) is planned change. Flashduty returns success and creates no alert.

​
FAQ

No. MONITORING means a fix is live and still being watched. The alert stays triggered until the incident is marked RESOLVED.
UNDERMAINTENANCE is ignored and is not a recovery signal. The alert recovers when the component returns to OPERATIONAL after the maintenance, or you can close it by hand in Flashduty.
No. Flashduty identifies the integration by the integration_key in the push URL and does not read the x-instatus-webhook-signature header. Keep the push URL private; if it leaks, delete the integration and create a new one.
In Instatus, open the subscriber under Subscribers → Webhook and click Unsubscribe, or delete the Flashduty integration.

​
Troubleshooting

  • No alerts in Flashduty: check that subscribers were notified when the incident or update was published. Scheduled maintenance and UNDERMAINTENANCE never create alerts
  • Flashduty returns an invalid parameter error: check that the push URL is complete (includes integration_key) and that the subscriber uses the default payload format. Payloads without page.id, an incident ID, or a component ID are rejected
  • Instatus emails you about failed deliveries: check that the integration still exists and the push URL has not changed
  • A component alert does not recover: check that the component is back to OPERATIONAL. Maintenance does not close the alert