Your telemetry stays yours
There's no central log store or metrics database sitting behind Sproobo. App and host telemetry lives only on your server; the control plane holds intent, audit, and operational deploy/backup records — never a copy of your logs or metrics.
Live log tailing
A log request goes through the agent's existing channel and streams to the dashboard over SSE, on demand — nothing is persisted on the way through. The CLI does the same thing:
sproobo logs --server <serverId> --container <name> -f-f streams; --tail sets the initial window (default 200 lines). sproobo logs --deployment <deploymentId> reads a specific deployment's build/deploy log instead — those are Sproobo's own operational records, not your app's runtime logs, so they're the one log type actually retained centrally.
If a server is unreachable, live logs simply aren't available — the dashboard shows the last fact snapshot and heartbeat status instead of a silent blank.
Metrics, live
Metrics graphs are live, not historical. While you have a server or app's live view open, the dashboard repeatedly asks the agent for a fresh CPU/RAM sample and keeps a short rolling window of the most recent points in memory to draw the chart. Close the tab and the window is gone — nothing is written to a database on either side.
Deploy diagnostics, captured automatically
When a deploy fails its health gate, the control plane automatically captures the failing container's last log lines and attaches them to the deployment record — no separate step, no re-running the deploy just to see why it broke. That same excerpt rides along in the deploy_failed notification below. See Apps & deploys for the health gate and rollback mechanics.
The alert catalog
Alerting only ever reports bad news — a failed deploy, an unreachable server, a failed backup. Five categories, computed from signals the control plane already has (the heartbeat, fact snapshots, and deploy/backup records) — no telemetry firehose required:
| Category | Fires when | Resolves | Severity |
|---|---|---|---|
| Server unreachable | The WSS heartbeat goes quiet past a threshold (default 180s, editable) | The agent reconnects | critical |
| Service down | A managed backing-service container reports unhealthy or not running | The container recovers | critical |
| Drift detected | The server's actual state diverges from the declared plan | Drift is reconciled or dismissed | warning |
| Deploy failed | A deployment flips to failed | — (one-shot) | critical |
| Backup failed | A backup, or a restore verification, fails | — (one-shot) | critical |
The first three are stateful: they open once and close with a second, distinct “resolved” notification the moment the condition clears, so a channel is never left showing a stale failure. The last two are one-shot: they fire once per event and never resolve — a failed deploy stays failed history, there's nothing further to report.
Two more lifecycle notifications ride the same channels and routing but aren't alerts in the bad-news sense: deploy_started and deploy_succeeded post an informational card (commit, branch, author) for every deploy. See Apps & deploys for what triggers a deploy in the first place.
Channels
Add as many destinations as you want, each routed to the categories it should hear about:
- Email — sent over an SMTP relay you (or Sproobo's hosting) configure. If none is configured, email is disabled in the channel picker with a clear reason; Slack and webhook channels are unaffected.
- Slack — a real workspace connection, not a pasted webhook URL. Click Connect Slack workspace, authorize the Sproobo app, then pick a channel from a live dropdown (public channels post immediately; a private channel needs the bot invited first). Disconnect the workspace at any time.
- Webhook — a generic HTTPS POST to any URL you give it, JSON body, with an optional signing secret: set one and every POST carries an x-sproobo-signature HMAC-SHA256 header so you can verify it actually came from Sproobo.
Every channel can be edited, disabled without deleting it, or deleted outright — and has a Test button that sends a real notification through it immediately, so you can confirm delivery before you need it for real.
The Alerts view
Anyone in the org (VIEWER and up) can see currently-firing alerts and history, filterable by server or category. Each alert shows its per-channel delivery status, so a failed send — bad SMTP credentials, a revoked Slack token — is visible in the dashboard, not silently swallowed.
Threshold alerts for disk usage, RAM, and TLS certificate expiry are designed but not shipped yet — the agent's fact snapshot doesn't carry those fields today. A self-serve way to forward your live telemetry to your own Loki/S3/Datadog-compatible endpoint is also on the roadmap, not yet configurable from the dashboard.
Next
- See what triggers a deploy and how the health gate decides pass/fail on Apps & deploys.
- Channel secrets and webhook signing secrets use the same envelope encryption as everything else — see Security model.
- Managing notification channels and routing requires ADMIN or above — see Team, orgs & billing for the full role breakdown.