CloudLine
Reference

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

  1. Raw events (uptime_events, bot_telemetry) — one row per heartbeat. Powers second-resolution charts, incident timelines, and the Telemetry panel's live tiles.
  2. 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

PlanRaw eventsDaily aggregates
Starter7 days1 year (365 days)
Pro30 days3 years (1095 days)
Business90 days5 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.