Alerts and notifications
Alerts work from the moment you create a monitor - no mail server to configure. This page covers when an alert fires, who receives it, and how to route it.
When an alert fires
By default, a single failed check does not alert on its own. Vantield re-checks first, about 5 seconds apart, up to the policy's consecutive failures threshold (1 to 5, default 2). If any re-check succeeds, the failure is treated as a blip and no one is notified. If every re-check fails, an incident opens - timestamped at the first failure - and the alert is sent.
- Threshold 1 alerts on the first failed check, with no re-check.
- Each outage produces one alert when it starts and, if enabled, one when it resolves - not an alert per failed check.
- Email alerts are retried automatically if delivery fails.
Who gets notified
Default policy
Every team has a built-in default policy that emails all active team members. New monitors use it unless you choose another policy. It works on every plan.
Custom alert policies (Pro and Enterprise)
Team admins can create named policies with:
- Consecutive failures - how many checks must fail before alerting.
- Notify on resolve - send a recovery alert when the monitor comes back (on by default).
- Recipients - any email addresses, including people outside your team.
Any custom policy can be set as the team default. A custom default policy notifies its own recipients in addition to all team members.
Delivery channels
| Channel | Plans | Notes |
|---|---|---|
| Email (zero-config) | All | Sent from Vantield's own mail infrastructure. Includes the monitor, URL, status, time, and a link to the monitor. |
| Custom SMTP | Pro, Enterprise | Send alert email through your own mail server instead. |
| PagerDuty | Enterprise | Events API v2. Opens a PagerDuty incident when the monitor goes down and resolves it on recovery. Each monitor keeps one PagerDuty incident per outage. |
Integration credentials, such as SMTP passwords and PagerDuty integration keys, are encrypted at rest.
Test before you need it
Test Alert on the monitor detail page sends a notification through the monitor's policy right away, ignoring the failure threshold. Test emails are marked [TEST] in the subject, and PagerDuty test events are sent at info severity so they do not wake anyone.
Mute and pause
| Checks run | Incidents recorded | Alerts sent | |
|---|---|---|---|
| Mute | Yes | Yes | No |
| Pause | No | No | No |
Both can be set for 6, 12, or 24 hours, or until you turn them off. Use mute when you want the record but not the noise - a known issue you are already working on. Use pause for planned maintenance, when failed checks would only add noise to your history.
Next: Dependency monitoring