Skip to main content
Use the Loadster webhook integration to send monitor failure (Monitor Fails) and recovery (Monitor Recovers) notifications to Flashduty On-call. Each monitor maps to one Flashduty alert: the alert triggers when the monitor fails 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, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Loadster 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 Loadster 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 Loadster

1

Enable webhooks

  1. Log in to the Loadster dashboard and go to Account → Integrations
  2. On the Webhooks card, click Enable Webhooks
2

Enter the push URL

  1. Paste the complete Flashduty push URL into both Monitor Fails Webhook URL and Monitor Recovers Webhook URL
  2. Leave the other two fields (Load Test Started / Load Test Finished) empty
  3. Click SAVE
Webhooks are configured per account and apply to every monitor in the account. Loadster sends an HTTP POST request when a monitor event occurs and treats a 2xx response from Flashduty as success. If a request fails, Loadster retries it periodically.
3

Verify the lifecycle

Make a monitor fail (for example, point an HTTP Request Monitor at a URL that returns 5xx) and confirm Flashduty receives a Critical alert. Once the target recovers, confirm the alert closes automatically.

​
Payload

Loadster POSTs the following fields as JSON. Flashduty parses them directly, so no template is needed: When the monitor name is empty, the alert title is Loadster monitor <monitor.id>.

​
Alert Key

Flashduty uses monitor.id as the Alert Key. The failure and recovery notifications of one monitor carry the same monitor.id, so they land on the same alert. Renaming the monitor does not change the Alert Key. The top-level id of the request is a new UUID for every notification and is not part of the Alert Key.

​
Status and severity

Loadster notifications carry no severity, so Flashduty maps them as follows: Notifications without monitor.id (for example, load test started and finished notifications) are acknowledged and ignored without creating an alert. The Loadster webhook has no test button.

​
FAQ

No. Loadster sends one failure notification when the monitor opens an incident and one recovery notification when it recovers; nothing is sent in between. Whether the first failed check opens an incident is controlled by the monitor’s Open an incident after N failures setting.
The Loadster webhook applies to the whole account. To separate monitors, use routing rules on a shared integration in Flashduty and match on the monitor_id or check label.

​
Troubleshooting

  • Loadster does not push: confirm webhooks are enabled and saved under Account → Integrations → Webhooks, and that both URLs are the complete push URL containing integration_key
  • Flashduty returns a parameter error: confirm the request body contains monitor.id and cycle.status
  • The alert does not recover: confirm Monitor Recovers Webhook URL is filled in and the recovery comes from the same monitor as the failure
For field details, see the Loadster documentation Integration with Webhooks.