Skip to main content
Use StatusGator’s Webhook integration (webhook version 3.0) to send monitor status changes to Flashduty On-call. StatusGator sends two notification types: StatusChange (a monitor’s status changed) and EarlyWarningSignal (a possible outage that the service has not confirmed). Each StatusGator monitor maps to one alert: the alert triggers when the monitor becomes down, warn or maintenance, and recovers when it returns to up.

​
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 StatusGator 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 StatusGator 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

​
In StatusGator

1

Add the Webhook integration

  1. Sign in to StatusGator and open Integrations in the page header
  2. Select Webhooks and click Add
  3. Paste the full Flashduty push URL as the Webhook URL and click Save
New Webhook integrations use version 3.0. A Webhook integration created before June 2025 may still use the deprecated version 2.0, whose body format differs and is not parsed by Flashduty. Delete it and add it again.
2

Send a test notification and verify

After saving, click Test integrations on the Webhook integration page, choose a status, a monitor and the Webhooks integration, then click Send test. Flashduty opens one separate Info alert titled StatusGator test notification, whatever status you pick. It never changes the monitor’s own alert, and it has no recovery, so close it by hand. Real status changes depend on outages of the monitored service and cannot be triggered on demand.
The Webhook integration is available on all Business and Education plans, including Free. If StatusGator does not get a 200 response five times in a row, it disables the webhook. Fix the URL on the Integrations page to re-enable it.

​
Payload

StatusGator POSTs JSON. The body is fixed and cannot be customized. Flashduty parses it directly, so no template is needed: The alert title is <monitor name>: <message>. When message is empty it is <monitor name> is <status>.

​
Alert Key

StatusChange uses monitor.id as the Alert Key. The StatusGator body has no event or incident ID, so the monitor is the only stable business object: the down, warn and up notifications of one monitor land on one alert, and different monitors produce different alerts. Changing the message, components, name or time does not change the Alert Key. EarlyWarningSignal uses its own Alert Key computed from a fixed prefix and monitor.id, so it never merges with the monitor’s status alert. Repeated early warnings for one monitor merge into one alert. If monitor.id is missing, Flashduty returns a parameter error, because a recovery could not be reliably matched to its alert.

​
Status and severity

Requests whose type or status is empty or unknown are rejected, so a request that cannot be classified never lands in the wrong alert lifecycle.

​
Early warnings do not recover

EarlyWarningSignal is a one-shot notification. StatusGator sends no matching recovery event and Flashduty does not close it when the service recovers. Enable auto-close on timeout for the channel, with 1 hour recommended.

​
FAQ

Yes. A test from Test integrations carries the message Test message for <board name>. Flashduty recognises exactly that message and opens one standalone Info alert under its own key, so a test never opens or closes a real monitor alert. There is no recovery for it; close it by hand.
Make sure the recovery is still sent through the same Webhook integration, and check on the Logs tab in StatusGator that the delivery with status set to up returned 200. The recovery and the original notification must carry the same monitor.id.
Yes. Non-connection failures are retried up to 20 times over about 24 days, with the delay growing from a few seconds to more than a day, and then discarded.

​
Troubleshooting

  • StatusGator shows failed deliveries or disabled the webhook: confirm the Webhook URL is the full push URL and includes integration_key
  • Flashduty returns a parameter error: confirm the request is a version 3.0 JSON notification and that type, monitor.id and status meet the requirements above
  • Duplicate alerts or alerts that never recover: check whether an old version 2.0 webhook is still configured
For field details, see the StatusGator documentation Webhook version 3.0.