How notifications work
An alert reaching you is the last step of a longer chain. Knowing the chain is the fastest way to answer “why didn’t I get told about that?” — the answer is almost always one specific link in it, and the Deliveries page shows exactly which one.
The path
Section titled “The path”- A source sends an event. Proxmox, Uptime Kuma, a script, a heartbeat — whatever it is, it lands as one event with a severity.
- Routing rules decide what happens to it. Rules run in order; the first match decides the route: dropped, kept in the inbox only, or opened as an incident. An integration preset runs underneath your own rules, for sources of that integration.
- An incident, if one opens, has a notification policy. Who gets told, whether it repeats, whether it escalates if nobody acknowledges — all set on the rule or the default route.
- Quiet hours and silences can hold a notice back without touching the incident itself — it still opens, still shows in the inbox, only the alert waits or never goes out.
- A destination sends it. Telegram, Slack, Discord, a signed webhook, or the phones paired through InfraInbox Push.
- The delivery is recorded either way, sent or not, with why.
Try an event runs this whole chain against a sample or a past event, live, with nothing sent and nothing stored — the fastest way to check a change before it matters.
Deliveries: sent, or why not
Section titled “Deliveries: sent, or why not”Every attempt to tell a destination something — not just the first alert, but every follow-up — is one row in Deliveries, including the ones that were held back. Nothing is silently dropped from this list, so it can always answer “who was told, when, and why not.”
Status:
| Status | Meaning |
|---|---|
| Pending | Queued; shown as “Retrying (n)” once it has already failed once |
| Processing | Being sent right now |
| Sent | The destination’s provider accepted it |
| Failed | Every retry was used up |
| Cancelled | No longer relevant (the incident moved on before it went out) |
| Skipped | Deliberately held back — see below |
Why a notice is skipped:
| Reason | What happened |
|---|---|
silenced |
An active silence or source mute matched the incident |
quiet_hours |
It arrived inside quiet hours, below that destination’s threshold |
flapping |
The incident is unstable; open/resolve notices pause until it settles |
cooldown |
This destination was already told about the incident more recently than its cooldown |
destination_broken |
The destination needs attention (a bad token, a revoked webhook) before anything more is sent |
no_edit |
The channel can’t edit an earlier message, so an acknowledgement or a manual resolve made elsewhere has nothing to update there (see what “edited in place” means) |
recovery_off |
That destination, or that route, has recovery notices turned off |
state |
The notice no longer matches the incident’s current state by the time it was due |
unverified |
On infrainbox.app only: nothing is sent for a workspace until an owner has confirmed their email address |
quota |
On infrainbox.app only: the workspace, or that one destination, has sent as much as it may today — see Usage and limits |
A test send — the Send test button on a source or destination — bypasses every one of these gates on purpose: it always goes out, so it always tells you whether the destination itself works.