Database & Data Retention
How Telescope stores check results and manages data retention.
Every check Telescope runs produces an event — a timestamped record of the monitor's status, response time, status code, and any errors. These events power your dashboards, uptime calculations, and alert history.
Time-partitioned storage
Check events are stored in weekly partitions. Each week's data lives in its own table, which provides two advantages:
- Fast queries — when you view a dashboard for "last 7 days", Telescope only reads that week's partition instead of scanning your entire history.
- Efficient cleanup — when data ages out of your retention window, Telescope drops the entire partition instantly instead of deleting millions of individual rows.
What's stored per check
Each check event records:
| Field | Description |
|---|---|
| Status | up, down, or degraded |
| Status code | HTTP status code (for HTTP monitors) |
| Response time | How long the check took (milliseconds) |
| Error | Error message if the check failed |
| Metadata | Type-specific details (e.g., WAF detection results, final URL after redirects) |
| Timestamp | When the check ran |
Monitor state
In addition to individual check events, each monitor maintains its current state:
- Status — the result of the most recent check.
- Last response time — how fast the last check was.
- Consecutive failures — how many checks in a row have failed. Resets to 0 on success.
- Last checked at — when the monitor was last checked. Used to schedule the next check.
This means your dashboard always shows the current state instantly, without needing to query the full event history.
Data retention
Check events include an expiration timestamp. Expired partitions are cleaned up automatically, keeping your database lean without losing the data you need for uptime reporting and incident review.