Skip to content

How sources work

A source is one thing that sends InfraInbox events: a Proxmox cluster, an Uptime Kuma instance, a script, a heartbeat, the InfraInbox agent. Every source belongs to one workspace, and every event it sends is scoped to that workspace — the source’s credential decides which workspace, never the request itself.

Start at Add source. The picker offers:

Entry What it’s for Guide
InfraInbox agent Docker on one host: container health plus a host heartbeat Docker and host agent
Proxmox VE / Backup Server The exact webhook configuration to paste in Proxmox VE and Backup Server
Uptime Kuma Monitor up/down as incidents Uptime Kuma
Alertmanager / Grafana Firing and resolved alerts Alertmanager and Grafana
Gotify-compatible Anything that already speaks Gotify or shoutrrr Gotify-compatible tools
A generic source Any script or tool that can POST JSON Events API

Every source gets its own credential the moment it’s created, shown once: an ingest key shaped like iik_src_…. Keep it — InfraInbox stores only a hash of it and can’t show it to you again; if you lose it, rotate it instead.

A key that ends up inside an event’s own text, for example in a cron job’s mail subject, is removed before the event is stored (event fields). It still leaked wherever the sender wrote it, so rotate it.

A source doesn’t declare what feeds it — InfraInbox only reports what has actually arrived, within the last minute. Its Setup tab lists up to four wiring kinds:

Kind Carries
api Anything posting JSON straight to the events API
webhook A tool’s own adapter (Proxmox, Uptime Kuma, Alertmanager/Grafana)
gotify A Gotify-compatible sender
heartbeat Liveness or job pings

Each row reads Receiving once traffic has arrived on it, or Idle otherwise — never “configured”, because a wiring you set up but never used would be honestly idle either way.

Every source shows two things, and they answer different questions.

Connection — is anything reaching this source at all:

State Meaning
Waiting for first request Nothing has arrived yet
Reachable A test or a tool’s own “Test” button got through, but no real event has
Receiving events At least one real event has arrived
Unknown Not yet determined

Health — is what’s behind this source actually okay right now:

State Meaning
Online Its liveness monitor, if it has one, is up
Degraded A job monitor is down, or an incident from this source is still open at WARNING or above
Offline Its liveness monitor is down
Unknown No liveness monitor is reporting — there is none, or the ones there are haven’t been pinged yet or are paused

Health only ever comes from a liveness monitor or an open incident — never from silence. A source that has gone quiet reads Unknown, not Offline, unless something is actually watching for that silence. See Heartbeat monitors to close that gap.

Every source has a Send test action (owner or admin). It fires one synthetic test event through the same path a real one takes, skipping rules, silences and incident correlation, and marks the source Reachable. It queues one test notice to every enabled destination, so it’s also how you check a Telegram chat or a webhook actually receives something. A tool’s own “Test” button, where it has one (Proxmox, Uptime Kuma), calls this exact path from the tool’s side.

  • Mute a source (from its detail page) to hold back its notices without losing anything: events still arrive, incidents still open, only the alerts stop. A mute is a silence narrowed to one source.
  • Rotate a source’s key from its Credentials tab if it may have leaked. The old key keeps working for 24 hours, so you have time to update the sender before it stops.
  • Delete a source once nothing needs it. Its past incidents stay readable.

A source the InfraInbox agent uses shows two links on its Heartbeats tab: View agents, this source’s own row in the Agents view, and, for an owner or admin, Settings for every agent of this source, the detection-settings editor every agent using this source’s key reads from.