Alerts & routing
What happens when a credential starts failing — when you are told, how often, where it is delivered, and how to prove the delivery works before you need it.
When a credential starts failing validation, PulsVault opens an alert and works through a lifecycle designed so that alerts stay trustworthy — loud enough to act on, quiet enough to keep believing.
The lifecycle#
| State | What it means | Are you told? |
|---|---|---|
| Degraded | failing, counting toward the threshold | no — not yet certain |
| Firing | the threshold was reached | yes — first notification |
| Suppressed | notified; in a 30-minute cooldown | no |
| Escalated | still failing after the cooldown | yes — second notification, higher severity |
| Escalated (ongoing) | still failing hours later | yes — a reminder roughly every 6 hours |
| Resolved | the credential works again | yes — a recovery notice |
Single-failure alerts are noise. The default 2 consecutive failures is what makes an alert worth trusting — when one fires, something is really wrong. A success at any point resolves the alert and resets the count.
Reminders, and how to stop them#
An alert that stays broken keeps reminding you roughly every six hours, so a credential nobody fixed does not fall silent and get forgotten. Reminders stop when:
- you acknowledge the alert — that is what the button means: someone has it; or
- the credential recovers; or
- the incident reaches its reminder limit after about two days, at which point it stays open and visible on the Alerts page but stops sending.
Snoozing pushes the next notification out by the window you choose without claiming ownership — right when you know the provider is in maintenance for an hour.
What does not alert#
Only genuine credential failures count. A timeout, or an error meaning the check itself could not be completed, is recorded in history and pages nobody — a network blip is not a broken credential.
The Alerts page#
A project → Secrets → Alerts lists every open alert for that project: severity, status, the path, how many consecutive failures, and — in plain language — what the alert will do next. "Quiet until 06:00, then reminds again" is a more useful thing to read than "SUPPRESSED".
Filter by environment to answer the only question that matters at 3am — is production affected? — plus by path and by status.
Acknowledge and Snooze are on each row. Both quiet an alert for everyone else, so they need
the secrets:validation:trigger permission — being able to see validation results is not enough.
End snooze only makes an alert louder again, so anyone who can see the alert may use it. You
only ever see alerts for projects you can open.
Snoozing, and undoing it#
Snooze silences an alert for a while you choose — 1 hour, 4 hours or 24 hours. It asks first, because what it does is easy to read backwards:
- The credential keeps being checked the whole time. A snooze hides nobody's failure; it stops the notifications about one you have already seen.
- Nothing is skipped. The alert does not move while it is quiet. When the window ends it carries on from exactly where it was — an escalated alert is still escalated, and its next reminder is still owed.
- It resolves on its own if the credential starts working again, snoozed or not.
A snoozed alert keeps its real status and gains a snoozed badge, and its row reads "Snoozed — quiet until 15:42". The Snooze button becomes End snooze: pressing it ends the window immediately and the alert can notify again from that moment. Both the snooze and the cancellation are recorded in the incident timeline, with who did it.
Acknowledge says I own this and stops the reminders for good — until the credential recovers. Snooze says not right now and stops them until a time you pick. Acknowledging an alert you will not act on today is the thing that quietly loses it.
The incident drawer#
Click any alert to open its incident:
- What broke — the failure reason, the last error, how many consecutive failures, and how long it has been failing.
- Where this delivers — the route that would carry the next notification and its channels, or a warning that nothing is configured to carry it at all.
- Timeline — every notification in order with which channel got it and which did not, plus every human action with who took it. "Slack got the escalation, email bounced" is a fact you can read months later.
When a delivery fails#
Each channel of a notification shows where it stands:
| Status | Meaning |
|---|---|
| Queued | Saved with the alert and about to be sent, usually within seconds. |
| Delivered | The channel accepted it. |
| Retrying | The destination timed out, was unreachable, or answered with a temporary error. PulsVault tries again after 30 seconds, 2 minutes, 10 minutes, 30 minutes and 2 hours. |
| Not delivered | The destination refused it (for example, a Slack webhook that was revoked), it no longer exists, it was changed after the notification was queued, or all six attempts failed. The reason is shown next to it. |
| Skipped | The route was deleted, or the channel was replaced by a different kind, after the notification was queued — or a newer notification of the same alert already reached that channel. |
A notification is saved together with the alert that caused it, so a restart or an outage on our side does not lose it. It is sent once that outage is over.
Fix the destination, then press Retry on a notification that was not delivered. The retry is sent to the channel as it is configured now, so a corrected webhook URL is the one that receives it. PulsVault never does that on its own: if a destination is changed while a notification is waiting, the notification stops at Not delivered instead of reaching the new recipients unannounced. Retry is not offered for a notification a newer one has already replaced, or for one recorded before retries existed. Retrying needs the same permission as acknowledging, and the timeline records who retried it.
Notifications of one alert reach a channel in the order they were raised, so "recovered" never arrives before the "failing" message it answers. A message can occasionally arrive twice: when a destination accepts a message but times out before confirming, PulsVault cannot tell, so it sends it again.
An alert opened before this record existed shows an empty timeline. New incidents record from the first notification onward.
Alert routes#
Under DevOps → Alert routes you define where notifications go. A route is a named set of channels plus a minimum severity.
| Channel | Delivery |
|---|---|
| Integration destination | a Slack channel or webhook you configured under Integrations — the preferred option |
| a list of addresses | |
| Slack | a webhook URL typed directly into the route |
| Webhook | an HTTPS endpoint typed directly into the route |
Pointing a route at a destination keeps the credential in one place, lets you rotate it in one place, and means the URL never has to be pasted into a second screen. The direct Slack and webhook channels exist for routes created before Integrations and still work.
Mark one route as the default for your space: it carries every alert whose path has not been given a route of its own.
Minimum severity#
A route only carries alerts at or above its minimum severity. Alerts are raised at Warning when they fire, and Error when they escalate.
Nothing in PulsVault raises an alert above Error, so a route cannot be saved with a higher minimum. A route that was saved at Critical before that rule existed delivers at Error. Set routes to Warning to receive everything.
Proving it works before you need it#
Every route has Send test, which delivers a real message through the same path a genuine alert takes — not a special test-only path that could pass while real alerts fail. The result is shown per channel, so a route where Slack works and email does not says exactly that, and it is kept with the route so you can see later whether anyone ever proved it.
A test email is sent once per set of addresses. Test again after changing the addresses and it sends; press it repeatedly with the same addresses and PulsVault reports the channel as already verified rather than sending again. Email leaves through a shared provider with a sending reputation everyone depends on, and proving the same thing twice is not worth spending it. Slack and webhook tests have no such limit — they reach your own endpoint.