Monitoring & health

A collector you can't see is a collector you can't trust. This page covers how to know your fleet is healthy and get told when it isn't — the difference between running a deployment and hoping.

Fleet health (staff)

Kilasec staff land on Fleet health — a cross-tenant board of every collector, live. It gives you, at a glance:

• A health strip: tenants, collectors online, collectors offline, and pending approvals.
• A collector table you can filter to all / offline / pending, showing each collector's state, which tenant it belongs to, how long it's been since its last heartbeat, its version, and its IP.

It polls every 10 seconds. When something goes dark, this is where you see which box, in which tenant, and for how long — without impersonating each tenant one at a time.

A single-tenant customer admin doesn't get the cross-tenant board, but sees their own collectors' status on the Collectors page and a first-run checklist on the Dashboard until traffic is flowing.

Liveness: how "online" is decided

Every collector heartbeats to the cloud roughly every 10 seconds (its uplink cycle). A collector counts as online if its last heartbeat was within 60 seconds. Two timestamps are tracked:

• last seen — updated on every heartbeat; "is it alive?"
• last event — updated only when real traffic flows through it; "is it actually inspecting anything?"

A collector can be online but idle (alive, no AI traffic yet) or online and busy. The board surfaces both so you can tell a quiet network from a broken one.

Offline alerting

Detection isn't enough — you want to be told. When a collector that was heartbeating goes dark for more than 5 minutes, Kilasec fires an operator alert (once per offline episode; it re-arms after the collector comes back). Alerts go to whatever channels you've configured:

• Slack-compatible webhook — set KILASEC_NOTIFY_WEBHOOK_URL.
• Email via Resend — set RESEND_API_KEY and KILASEC_NOTIFY_EMAIL_TO.

These are cloud-side environment settings (systemd drop-in on the VM for the self-hosted cloud). With neither set, offline events are still visible on the board but nothing is pushed. Set at least one before running a beta unattended — otherwise an outage is invisible until someone happens to look.

The same channel also notifies you when a new beta prospect signs up on the marketing site.

The health endpoint

GET /healthz is a real probe suitable for external uptime monitoring:

{ "ok": true, "service": "agentfw-cloud", "db": "ok", "collectors": 3, "collectors_online": 2 }

It probes the database and returns HTTP 503 when degraded (e.g. the DB is unreachable), so a monitor actually trips instead of getting a hardcoded ok. Point your uptime checker (Better Uptime, Pingdom, a simple cron + curl) at https://kilasec.com/api/healthz and alert on non-200.

A monitoring baseline for a beta

1. Configure an alert channel (webhook or email) so offline events reach you.
2. Add external uptime monitoring on /api/healthz.
3. Glance at Fleet health on your normal cadence; filter to offline first.
4. Watch the approval backlog — a growing pending approval count means requests are being held and nobody's resolving them.

When a collector shows offline

See Collector is offline for the triage steps — reachability, the container, the uplink, and the host.