WebCheck may wait before sending an incident alert because it first confirms consecutive failures and then applies the site’s “Notify after” delay. The check result and incident state are recorded before that notification delay finishes.
Incident confirmation comes first
By default, a target needs two consecutive Failed or Blocked runs before WebCheck opens an incident. The target’s threshold can be set from one to ten. Passed and Degraded runs break the failure sequence. An eligible HTTP connection failure can also be retried within its check run before that run is recorded.
Check the site notification delay
When configuring a notification destination, the site detail page offers “Notify after” choices of Immediately, 5 minutes, 10 minutes, 30 minutes or 1 hour. This delay applies to incident-open and recovery notifications for the site. Recovery notices use the same delay.
The delay does not postpone the check, incident record or site status. Certificate and domain-expiry warnings are separate events and do not use this incident notification delay.
If an alert still has not arrived
Open the site’s check history and confirm whether an incident was opened. Then review the notification destination and Account email address. Queue processing and the receiving email or webhook service can add further delivery time; WebCheck does not show delivery records on the site detail page.