Retention policy
Two-tier retention — raw events for short-term resolution, daily aggregates for long-term trends. What's kept, for how long, on which plan.
CloudLine stores your bot's history in two tiers so you get high-resolution data for recent windows AND multi-year trends without storing everything at second-resolution forever.
The two tiers
- Raw events (
uptime_events,bot_telemetry) — one row per heartbeat. Powers second-resolution charts, incident timelines, and the Telemetry panel's live tiles. - Daily aggregates (
uptime_daily) — one row per bot per UTC day. Aggregated uptime %, average latency, incident count. Powers long-term uptime trends.
The Monitor view picks automatically: zoomed-in windows use raw events; zoomed-out windows fall back to the 5-minute aggregate (uptime_buckets, kept for 7 days) and then to daily aggregates beyond that.
Per-plan retention
| Plan | Raw events | Daily aggregates |
|---|---|---|
| Starter | 7 days | 1 year (365 days) |
| Pro | 30 days | 3 years (1095 days) |
| Business | 90 days | 5 years (1825 days) |
The raw-event retention is the practical limit for high-resolution charts. Beyond it, the chart automatically uses the 5-min aggregate first, then daily — you still get the line, the per-tick fidelity just drops off.
What's actually retained
uptime_events
Per-heartbeat row with status + telemetry. Used for:
- Status timeline (the colored ribbon at the top of the Monitor view)
- Latency / CPU / memory sparklines
- Incident reconstruction (when did the bot first go offline, when did it come back)
Each row carries about 30 fields — see Raw HTTP for the full list.
Pruned daily by the BotMonitor Durable Object — anything older than the plan's retention is deleted in batches.
bot_telemetry
A wider row capturing every metric the bot reports per heartbeat. Used for the Telemetry panel's live tiles and for the custom metrics history.
Same retention as uptime_events — pruned in lock-step.
uptime_buckets
5-minute rollups. Each row is a single bucket with online_checks, degraded_checks, offline_checks, average / min / max latency.
Retained for 7 days on all plans, then trimmed once the daily aggregate has taken over. The 5-minute window is the middle ground for charts that span days but aren't long enough for the daily aggregate to be useful.
uptime_daily
One row per bot per UTC day. The long-term archive.
Computed daily by an alarm tick: takes the 24-hour slice of 5-min buckets and aggregates them. The 5-min buckets that fed into a daily aggregate are trimmed by the retention prune; the daily row persists for the per-plan retention.
Used for:
- Year-over-year uptime trends
- Custom date ranges that exceed your raw retention
- "When was the last time this bot had 100% uptime for a week?" style queries
incidents
One row per offline → recovery cycle. Includes the start time, end time, and duration (the SEV1 / SEV2 / SEV3 label is derived from the duration at display time).
Resolved incidents are pruned at your plan's raw-retention window (Starter 7 days / Pro 30 days / Business 90 days) by the same daily BotMonitor cleanup. An active (still-open) incident is never pruned — it's kept until it resolves, so you never lose the start time of an ongoing outage. Incidents are a small dataset (a healthy bot might have 0–5 a month).
alert_history
One row per alert sent (offline / recovery / latency_high / CPU / etc.), with delivery channel and success/failure status.
Retained for your plan's raw-retention window (Starter 7 days / Pro 30 days / Business 90 days) and paged in the dashboard's Alerts tab. Older rows are removed by the daily BotMonitor cleanup.
error_events
Per-error row from monitor.captureError() and the auto-captured discord.js / discord.py events.
Same raw-retention window as uptime_events (Starter 7 days / Pro 30 days / Business 90 days), pruned in lock-step by the daily BotMonitor cleanup.
What you keep when you downgrade
Downgrading from Pro → Starter (or Business → Pro) does not delete your historical data. What changes:
- Future raw-event retention is the new plan's window.
- Existing rows that are within both plans' windows stay.
- Existing rows that are older than the new plan's window are pruned in the next daily cleanup.
Example: you're on Pro (30 days raw), have 25 days of raw events. You downgrade to Starter (7 days raw). The next prune trims anything older than 7 days. Your daily aggregates for those days remain (Starter retains 1 year of dailies).
When charts use which tier
The Monitor view tries hardest to give you the highest-resolution data the plan allows:
- Window ≤ raw retention (e.g. last 24h) → raw events, full second-level resolution.
- Window ≤ 7 days but raw retention exceeded → raw events for the recent part + 5-min buckets for older part. Visible as a slight chart smoothing on the older slice.
- Window > 7 days → 5-min buckets for the recent part + daily aggregates for older. Chart smooths into one-data-point-per-day past the bucket window.
You never see "no data" for a window inside retention — the resolution just steps down. The 100%-coverage promise applies to all four tiers.
CSV export (Business)
The Business-plan CSV export (Settings → Export) downloads raw events for the currently selected range. If your window exceeds the 90-day raw retention, the older slice is empty in the CSV — the daily aggregates aren't included in the raw export.
For daily-aggregate exports, contact support.
Programmatic deletion
There's no public API to delete history. If you delete a bot from the dashboard, all of its rows in every table above are deleted within minutes (a background cleanup runs the cascade so the bot-delete request returns immediately).
To delete a single incident (e.g. a misfire from a misconfigured snippet), use the Incidents tab → ⋯ menu → Delete action on the row itself.