down and up state changes to Flashduty On-call. Each monitoring job maps to one Flashduty alert. A job going down creates the alert, notify_repeat notifications merge into it, and the job coming back up recovers it.
In Flashduty On-call
Create either a dedicated or shared NS1 alert integration and copy its complete Push URL.Configure NS1 Connect
1
Create a webhook notifier in NS1 Connect
Where: NS1 Connect › Alerts › Notifier lists › Create notifier list › Create notifierYour account needs the Manage notifier lists permission. Create a notifier list, or open an existing one, and add the notifier:
Click Create notifier, and save the notifier in the list (click Create notifier list).
2
Enable notifications on monitoring jobs
Where: NS1 Connect › MonitorsOpen the monitoring job that should alert (new or existing), select the notifier list from the previous step in its notification settings, and keep Notifications on enabled.
3
Verify the lifecycle
Where: NS1 Connect › MonitorsMake the monitored endpoint genuinely unreachable and confirm Flashduty receives a Critical alert. Then restore the endpoint and confirm the same alert recovers. NS1 notifiers have no documented test button, so verify with a real state change.
Alert key
Flashduty uses the monitoring job ID,job_document.id, as the Alert Key. NS1’s official example of the down body carries the full job_document, whose id is the job ID. The down, repeated, and up notifications of one job share it.
If the job has job_document.notify_regional enabled, NS1 notifies per region. The Alert Key is then job_document.id/region, each region has its own alert, and one region recovering does not close another region’s alert. When it is off, the region is not part of the Alert Key, so a down and an up observed from different regions belong to the same alert.
Changes to the job name, the since timestamp, the region that observed the change, or the check configuration do not change the Alert Key.
NS1’s official documentation shows the full
down body only; its up example is truncated after since. Flashduty assumes the up body carries the same job_document. If an up body has no job_document.id, Flashduty rejects it instead of guessing which alert it belongs to.Status and severity
NS1 sends no severity.state is case-insensitive.
Labels
Flashduty keeps the labelscheck (job name), resource (host, url, or domain from config), job_id, job_type, region, state, and notify_list for troubleshooting and routing on the alert page.
Troubleshooting
- The alert does not recover: confirm Notify failback is enabled on the monitoring job. If you cannot enable it, turn on auto-close timeout for the channel with a duration of 1 hour and the timer starting at incident trigger
- NS1 reports a webhook failure: confirm the Push URL is complete and includes
integration_key - Flashduty returns
job_document.id is required: the body has no monitoring job ID; check that the notification was sent by an NS1 monitoring job - Several alerts after enabling regional notifications: this is expected, each region is an independent alert