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 | Never (one-shot) | critical |
| Backup failed | A backup, or a restore verification, fails | Never (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.