---
title: Data retention and history limits in WatchFor
description: How long WatchFor keeps each kind of monitoring data on each plan — uptime and incidents forever, check results, charts and artefacts per plan — and what the dashboard and API do at the edge.
canonical: https://watchfor.io/docs/organization/data-retention
---

# Data retention and history limits in WatchFor

How long WatchFor keeps each kind of monitoring data on each plan — uptime and incidents forever, check results, charts and artefacts per plan — and what the dashboard and API do at the edge.

WatchFor keeps different kinds of data for different lengths of time. The
history that answers "were we up?" is never cut; the detail behind it is kept
for a window that grows with your plan.

| Data | Free | Starter | Pro | Business | Enterprise |
| --- | --- | --- | --- | --- | --- |
| **Uptime, SLA & incident history** | Unlimited | Unlimited | Unlimited | Unlimited | Unlimited |
| **Check history** — every check result | 30 days | 30 days | 90 days | 180 days | Custom |
| **Charts & reports history** | 3 months | 2 years | 3 years | 5 years | Custom |
| **Screenshots, traces & Lighthouse reports** | 7 days | 30 days | 60 days | 90 days | Custom |
| **Activity log** | 30 days | 1 year | 1 year | 2 years | Custom |

The [pricing page](/pricing) always shows the current values for every plan —
it reads them from the same plan settings the product enforces.

## What each window covers

- **Uptime, SLA & incident history** — every incident with its timeline,
  notes and post-mortem, the uptime percentage on monitor cards, the
  **Uptime SLA** tab (any date range, printable), status-page uptime bars and
  the uptime and incident figures in reports. Kept on every plan with no time
  limit.
- **Check history** — each individual check: timings, status code, the
  stored response body, the error, and the per-check detail behind it. That
  includes the monitor's **Probes** list and check details, the probe results
  shown on an incident, the MTR day view and replays, MCP tool-inventory
  changes, individual Lighthouse audits and browser-check runs (with their
  per-step timings). For HTTP, SMTP, MTR, Brotli and favicon monitors the
  full response of a **successful** check is kept as a short-lived sample,
  separate from the check history: about the last 8 per location (one every
  10 minutes), for at most 2 days — enough to open **View result** on a
  recent green row. Failed checks keep their response for the whole check
  history.
- **Charts & reports history** — response-time, check-success, latency and
  p95 charts on the monitor page, the check-based parts of reports (check
  success, response time, per-location latency) and the response-time fields
  of the uptime API. Beyond your check history these come from hourly and
  daily summaries kept for the whole chart window, so the Lighthouse score
  trend and the browser-check duration trend continue there as one point per
  hour.
- **Screenshots, traces & Lighthouse reports** — browser-check failure
  screenshots and traces, page-integrity screenshots, and full Lighthouse
  reports with their filmstrips. Browser-check screenshots and traces are
  kept at most 365 days on any plan: the runs that point at them are kept
  400 days.
- **Activity log** — the organization's [audit trail](/docs/organization/activity-log).

## How charts reach back

Charts and reports read exact per-check data for ranges within the last 30
days and pre-computed hourly and daily summaries for longer ranges. The
summaries keep counts, sums, minimums, maximums and percentile sketches, and
they are written together with each check, so an average, a minimum, a
maximum or a success rate over any range is the same number the individual
checks give; p95 and p99 are estimates either way. Response-time figures
(average, minimum, maximum, p95, p99) cover **successful checks only**: a
failed check — a timeout, a refused connection — has no response time, so it
never drags an average toward zero. A range or location with no successful
check shows no response time rather than 0 ms.

- A range that reaches **further back than 30 days** is drawn from the hourly
  and daily summaries for every whole hour in it — the current hour included
  — and from the individual checks only for a partial hour at its start or
  end. A short custom range that far back (a few hours, a day) shows hourly
  points.
- **Filtering by location** (or the per-location table) uses an hourly
  per-location summary of response time and success. The detailed timing
  phases (DNS, connect, TLS, first byte …) per location go back as far as
  your check history.

## When data is deleted

Data is deleted from storage when its window ends — check results after the
check history, chart summaries after the chart history, screenshots, traces
and Lighthouse reports after their window. Each record keeps the window of
the plan it was recorded under. Deleting a monitor or an organization, or
resetting a monitor's history, removes its data straight away.

## In the dashboard

- **Range pickers** keep every option. Ranges that reach past your plan's
  history are shown locked with an **Upgrade** link instead of being hidden,
  and the picker says how far back your plan goes. On the **Probes** tab the
  check history applies; everywhere else on the monitor page, the chart
  history.
- Where a list or calendar ends at your plan's window — the Probes list, the
  MTR calendar, MCP inventory changes, browser-check runs, the activity log —
  a quiet line says so: *"Check history on Free goes back 30 days —
  Upgrade"*.
- **Incidents never disappear.** On an incident older than your check
  history, the timeline, root cause and notes stay; only the raw probe
  results behind it are no longer shown.
- **Reports** cover any period for uptime and incidents. If a custom period
  starts before your chart history, check success and response times start at
  that point and the report says so; a comparison period that reaches past it
  shows no baseline rather than a misleading one.

## In the API, MCP and A2A

The REST API applies the same windows and **cuts** a request that reaches
past them instead of failing it, so a plan change never breaks an
integration. Responses that read history carry three headers:

| Header | Meaning |
| --- | --- |
| `X-History-Limit-Days` | Your plan's window for this data in days, or `unlimited` |
| `X-History-Earliest` | The oldest timestamp your plan returns (ISO 8601) |
| `X-History-Clamped` | `true` when the requested window was cut to that point |

A single check or browser-check run older than your check history returns
`404 not_found` with a message naming your plan's window. Reports add
`meta.history` (`chartHistoryDays`, `dataFromMs`, `clamped`). MCP tools add a
`history_notice` to the result when a window was cut. See
[Checks & uptime](/docs/api/checks-uptime) and [Reports](/docs/api/reports).

## Changing plans

**Upgrading lengthens retention for new data only.** Everything recorded
from the upgrade on is kept for the new plan's windows. Data recorded before
it keeps the window it was stored with and is still deleted on that original
schedule — until then the longer windows already apply when you view it.
**Downgrading** narrows the windows at once: history older than the new
plan's window is no longer shown (it is deleted when its original window
ends), and uptime and incident history stay complete.
See [Billing & plans](/docs/organization/billing#changing-plans).

---

Canonical page: https://watchfor.io/docs/organization/data-retention · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt