Core concepts

A short definition of everything, then a bit more detail on the ones worth it.

Term	One line
Source	The app, host or script you want alerts about.
Wiring / integration	How a source actually gets events in — the API, a tool’s own webhook, Gotify compatibility, or a heartbeat.
Key / credential	The secret a source or monitor authenticates with.
Event	One thing that happened, as a source reported it.
Incident	A problem, grouped from its events by fingerprint.
Fingerprint / dedup	What decides which events belong to the same incident.
Severity	How serious an event is: DEBUG, INFO, SUCCESS, WARNING, ERROR, CRITICAL.
Destination	Where a notice is sent: Telegram, Slack, Discord, a webhook, or the built-in push.
Rule / route	What decides an event’s disposition and which destinations hear about it.
Default route	The rule every event falls back to when no other rule matches.
Preset	A source type’s ready-made rules and severities, applied when you add it.
Silence	A time-boxed filter that blocks notices without changing what happened.
Mute	A silence narrowed to one source.
Quiet hours	A daily window in which only severe-enough notices still go out.
Heartbeat monitor	A deadline a host or job must ping within, or it’s down.
Acknowledge / snooze / resolve	The three things you can do to an open incident.
Connection / health	The two independent readings a source’s status shows.
Delivery / notice	One attempt to tell one destination about one incident.

Source

The thing you want alerts about: a Proxmox cluster, an Uptime Kuma instance, a Docker host, a script. Every source belongs to one workspace and gets its own credential. A source doesn’t declare what feeds it — InfraInbox reports what has actually arrived. See How sources work.

Wiring / integration

One source can have more than one way in: the generic events API, a tool’s own webhook adapter (Proxmox, Uptime Kuma, Alertmanager/Grafana), Gotify compatibility, or a heartbeat ping. Each shows as Receiving once traffic has used it, or Idle otherwise.

Key / credential

A secret that authenticates a request: an ingest key (iik_src_…) for a source, a heartbeat token (iik_hb_…) for a monitor, a signing secret (whsec_…) for a webhook destination. Shown once at creation; InfraInbox stores only a hash. See Keys and credentials.

Event

One occurrence as a source reported it: a title, a severity, optionally a resource, a dedup key, a body and tags. Events are immutable once stored. See Event fields and severities.

Incident

A problem, grouped from its events by fingerprint (the incident’s identity). Its title and severity are its latest event’s; its peakSeverity is the highest it has reached, which is what “escalated” means. See How incidents work.

Fingerprint / dedup

What groups events onto the same incident, in priority order: the sender’s own dedupKey (verbatim, case-sensitive) if it sent one; otherwise a source-adapter’s own correlation key; otherwise the event’s type, resource and a normalized title. Fingerprints are always scoped to one source — the same fingerprint on two different sources never merges.

Severity

One of DEBUG, INFO, SUCCESS, WARNING, ERROR, CRITICAL, ranked in that order (INFO and SUCCESS rank equally). SUCCESS always acts as a recovery. A request may also send the aliases warn, err, crit and fatal.

Destination

Somewhere a notice can be sent: a Telegram chat, a Slack channel, a Discord channel, a signed webhook, or InfraInbox Push (the built-in destination for paired phones, always available).

Rule / route / default route

A rule matches events and decides their route: open an incident, log to the inbox only, or drop them — plus which destinations hear about it and on what policy (re-notify, cooldown). Rules run top to bottom; the first match wins. The default route is what every event falls back to when no rule matches — one notification policy per severity, beside the always-on InfraInbox Push.

Preset

A source type’s own starting rules, applied automatically when you add that kind of source — for example, Proxmox’s preset sets severities and quiet-window defaults per event type.

Silence

A time-boxed set of conditions (source, resource, type, severity, tags) that blocks an incident’s alerting notices without changing anything else: the incident still opens, still shows in the inbox, only the notices are held back.

Mute

The same idea as a silence, narrowed to exactly one source, either for a time or until you unmute it.

Quiet hours

A workspace-wide daily window (start and end time, in the workspace’s time zone) during which only notices at or above a destination’s own threshold still go out. The shipped threshold is CRITICAL.

Heartbeat monitor

A deadline a host or a job must ping within. There are two kinds: a liveness monitor proves a host or site is up (only it can make a source Offline); a job monitor proves a job ran and succeeded (a missed run degrades the source but never marks it offline). See Heartbeat monitors.

Acknowledge / snooze / resolve

The three actions on an open incident, from the inbox or a paired phone:

• Acknowledge — says someone has seen it. Stops repeat notices; doesn’t close it.
• Snooze — holds it quiet until a time you pick, then it reopens on its own.
• Resolve — closes it by hand.

See How incidents work for exactly what each one does to other channels and to re-notify.

Connection states

A source’s connection answers “is anything reaching this source at all”: Waiting for first request, Reachable (a test got through, no real event yet), Receiving events (a real event has arrived), or Unknown. Its health is a separate reading of whether what’s behind it is actually okay — see How sources work.

Delivery / notice

One row recording one attempt to tell one destination about one incident: pending, processing, sent, failed, skipped or cancelled, with why. An incident’s “Who was told” is built from these.