Background Workers
A lot of CloudPeek's value comes from work that happens automatically, around the clock, without anyone pressing a button. That work is done by background workers, separate processes that run continuously alongside the web app and API.
This page explains, in plain language, what the workers are and how they fit together. You don't configure most of this directly; it's useful background for understanding why incidents arrive already analysed.
What the workers do
Think of the workers as a night shift that never clocks off. Between them they:
- Pull in alerts from your connected tools (the intake worker).
- Triage each new incident with AI (the triage worker).
- Run the follow-up steps triage suggested, using read-only access to your tools (the follow-up worker).
- Hunt for patterns across many incidents (the threat-hunting worker).
- Keep the Wiki current by turning what's observed into knowledge-base updates (the wiki auto-indexer).
- Keep the live UI feed reliable and perform housekeeping.
The workers at a glance
| Worker | What it does | Roughly how often |
|---|---|---|
| Incident Sync | Polls connected alert sources, dedupes, creates incidents, queues them for triage | every ~60s |
| Triage | Runs each pending incident through the AI triage pipeline | every ~30s |
| Triage Requeue | Safety net: re-queues any incident that slipped through | every ~5 min |
| Follow-up | Executes the investigation steps triage produced (read-only) | every ~60s |
| Threat Hunting | Scans recent incidents for cross-incident patterns | every ~60 min |
| Wiki Auto-Indexer | Turns observed entities into Wiki page updates | every ~5 min |
| Event Retry / Health | Keeps the live event feed reliable | every ~30s / 5 min |
These intervals are sensible defaults that an operator can adjust per environment.
How it flows together
How work is coordinated
Two ideas worth knowing:
- Queues. Workers don't constantly scan the database; instead, work is placed on queues and picked up by whichever worker handles that queue. CloudPeek uses a Redis-backed queue system for this. A small companion scheduler process is the "alarm clock" that tells each queue "do this every N seconds."
- The real backlog lives in the database. The queues mostly carry timer wake-ups; the actual list of incidents to triage or follow-ups to run is kept in database tables, picked up safely so two workers never grab the same item. This is why CloudPeek can scale workers horizontally and never double-process an incident.
When there's a backlog, workers re-trigger themselves immediately (a "fast-tail" mechanism) rather than waiting for the next scheduled tick, so a flood of alerts is worked through quickly, while the schedule remains a safety net.
Reliability built in
- Retries with backoff. If a step fails for a transient reason (a rate limit, a timeout), it's retried later with increasing delay. Genuinely unrecoverable errors (bad credentials, a missing tool) fail fast but keep any partial results for inspection.
- Stuck-work recovery. Items that have been "in progress" too long are automatically reset and retried.
- Health checks. A heartbeat and queue-depth monitoring let the platform detect and react to problems (including autoscaling based on the real backlog).
A note on tenant isolation
Normally CloudPeek enforces strict per-request tenant isolation. Workers are the one deliberate exception: a single worker processes many tenants, so it runs under a special database role that can see across tenants. This is by design and tightly controlled, see Platform Architecture.
What you can configure
Most worker behaviour is set by operators at the deployment level (schedules, batch sizes, concurrency). The things you'll more commonly control from the app:
- Which tools are alert sources, and their polling schedules (see Tools & Integrations).
- Alert silencing rules and triage cooldowns, to stop known noise being triaged (see Admin & Settings).
- Hunt rules, to control threat hunting (see Threat Hunting).
- The AI model workers use, per tenant (see Admin & Settings).
Read on
- Automatic Triage: exactly what the triage worker does, step by step.
- Follow-up Actions: how investigation steps are run safely.
- Threat Hunting: finding patterns across incidents.