Skip to main content
Use Atlassian Statuspage subscriber webhooks to send changes on an upstream service’s status page to Flashduty On-call. The public status pages of many services, such as GitHub and Atlassian, are hosted on Statuspage. After you subscribe, a Flashduty alert triggers when a component goes into an outage state or the status page publishes an incident, and recovers when the component returns to operational or the incident is resolved. Subscribers need no Statuspage account and pay nothing. The Webhook option appears in a page’s subscribe menu only when the page owner has enabled webhook subscriptions.

​
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 Atlassian Statuspage 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 Atlassian Statuspage 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

​
Subscribe on a Statuspage status page

1

Open the subscribe menu

Open the status page you want to follow (for example, https://www.githubstatus.com), click Subscribe to updates, and select the webhook icon.If there is no webhook option, the page owner has not enabled webhook subscriptions, and this integration cannot receive updates from that page.
2

Enter the push URL

  1. Webhook URL: paste the full push URL of the Flashduty integration, including integration_key
  2. Email address: enter a team mailbox. Statuspage emails this address when the push URL returns an error
  3. Click Subscribe. If you receive a confirmation email, follow its instructions
One integration can subscribe to several status pages. Alerts from different pages are told apart by page ID and never merge or close each other. You can also create one integration per upstream service to route each one separately.
3

(Optional) Subscribe to your own team's status page

If your team runs a status page on Statuspage, first go to Subscribers → Options → Settings in the Statuspage management console, select Webhook under Delivery types, and save. The webhook option then appears in the page’s subscribe menu. The Free plan can enable it too. Then subscribe as in the previous step; a page that is not activated yet can also be subscribed to by a logged-in team member, which is handy for a first check.
4

Verify

Statuspage has no button to send a test notification. An alert appears in Flashduty only after the next component status change or incident update on the page.If your team runs a Statuspage page, you can use it to verify: change a component’s status to Major outage and a Critical alert appears in Flashduty; change it back to Operational and the alert recovers. When you create an incident in Statuspage, select at least one affected component, or Statuspage sends no notification.

​
Payload

Statuspage posts one JSON body each time a component changes status and each time an incident is updated. There are two kinds: Component status change The alert title looks like API Requests: major outage. Incident update Every alert also carries the label source=statuspage. The unsubscribe link in the payload (meta.unsubscribe) contains the subscription credential, and Flashduty never writes it into the alert.

​
Alert Key

Flashduty builds the Alert Key per payload kind:
  • Component: status page ID + component ID. Every status change of one component, from outage to recovery, lands on the same alert
  • Incident: status page ID + incident ID. Every update of one Statuspage incident, from investigating to resolved, lands on the same alert
Component alerts and incident alerts are independent. One upstream outage usually produces both; use the channel’s alert grouping to group them into one incident. Renaming a component or incident, or changing the impact, does not change the Alert Key. When the severity rises (for example an incident’s impact changing from none to critical), 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 Statuspage incidents The alert severity comes from the impact (impact), and the alert status from the incident status (status): Scheduled maintenance (status scheduled, in_progress, verifying, or completed, or impact maintenance) is planned change: Flashduty returns success and creates no alert.

​
FAQ

No. monitoring means a fix is deployed and being watched. The alert stays triggered until the status page marks the incident resolved.
under_maintenance is ignored and is not a recovery signal. The alert recovers when maintenance ends and the component returns to operational, or you can close it manually in Flashduty.
The Statuspage unsubscribe link appears only in the payload, and Flashduty does not keep it. You can delete the Flashduty integration, or ask the status page’s owner to remove the subscription; Statuspage emails the address you entered when deliveries fail.

​
Troubleshooting

  • The status page has no webhook subscribe option: the page owner has not enabled webhook subscriptions, so this integration cannot subscribe to it
  • Flashduty returns an invalid parameter error: make sure the push URL is complete (including integration_key). Payloads without page.id, a component ID, or an incident ID are rejected
  • Statuspage emails that deliveries fail: Statuspage requires a 2xx response within 30 seconds. Make sure the integration still exists and the push URL has not changed
  • A component’s alert does not recover: make sure the component is back to operational; maintenance does not close the alert