Alerts that mean something
Incidents notify. Rule breaches batch.
An incident is a state that opened. It is created the moment a check transitions from passing to failing, it notifies immediately, and it closes itself when a run passes again — which also notifies, because “it is back” is the message people are actually waiting for.
An alert rule is a threshold you defined: response time above a value, uptime below a percentage. Breaches are collected and delivered as a periodic digest.
That split is not a preference. A rule whose message contains a moving figure produces a new row on every check, so an hour of downtime generates over a hundred of them. Notifying per row would be a billing incident on SMS and a muted mailbox on email.
Where alerts go
Channels belong to the organization rather than to a person, and can optionally be scoped to a single cluster so a noisy staging environment does not reach the same phone as production.
- Resend
- SMS
- Twilio
- Webhook
- HMAC signed
- Default digest window
- 60 minutes
Each channel carries its own minimum severity and can opt out of incidents or digests independently — an SMS channel for critical incidents only, an email channel that also takes the hourly digest.
Webhooks are signed. Every request carries an HMAC of the body computed with a secret shown to you once, at creation, so your receiving endpoint can verify a payload really came from Pulse.
Deliberate silence is recorded
When Pulse decides not to send something, that decision is written down. An unverified channel, a send budget reached, a plan that does not include the feature, an incident that resolved before the message was processed — each leaves a row in the delivery log marked skipped, with the reason.
The alternative is a system that silently does nothing, and a person staring at a dashboard wondering whether the alerting is broken or the site is genuinely fine. Not knowing which is worse than either.
What can raise an alert
A distinct alert type per check, which is what lets one check’s recovery avoid closing another check’s open alert:
- Site down, or a response slower than your threshold
- Certificate invalid, or approaching expiry
- Domain approaching expiry
- Content assertion no longer matching
- DNS records changed
- A required security header missing
- Performance, SEO, exposure and broken-link findings from test runs
Events versus states
Most alerts describe a state: the site is down, the certificate is invalid. Those resolve themselves when the next check passes, which is exactly right.
Drift alerts describe an event: a DNS record changed, a header disappeared. Those are never auto-resolved, because a check passing an hour later has not undone the thing that happened. Without that distinction every drift alert would quietly clear itself on the following run and you would never see one.
Common questions
- How many messages does an hour of downtime send?
- Two: one when the incident opens and one when it resolves. An hour of downtime at a five-minute interval produces about a dozen failed runs, and the alert rules layered on top can produce over a hundred alert rows. All of that collapses into a single incident, and notifications are sent on the transition rather than on each failed run.
- Do I have to verify a channel before it receives anything?
- Yes, for email and SMS. A verification code is sent to the destination and must be entered before the channel will receive any other message. Editing the destination of an existing channel resets that verification, so verifying your own address and then swapping in somebody else's does not work. Webhooks are verified at creation, since you demonstrate control of the endpoint by receiving the signing secret.
- What happens when a notification is not sent?
- It is recorded as skipped, with the reason. Unverified channel, over the send budget, wrong plan, incident already resolved by the time the message was processed - all of them leave a row in the delivery log rather than disappearing. Silence you can explain is worth far more than silence you have to guess about.
- Can a flapping site run up a large SMS bill?
- No. There is a send budget per channel, and deliveries beyond it are skipped and recorded rather than sent. The same phone number also cannot be registered twice in one organization, so one incident cannot be billed twice to the same destination.
- Does a DNS change or a missing security header page me?
- No. Drift is recorded as an event and shown in the alert list, and the check goes degraded, but no incident opens and no immediate notification is sent. A planned DNS edit is not an outage. Event alerts are also never auto-resolved by a later passing check, because a check passing an hour later has not undone the change that happened.