---
title: Uptime reports in WatchFor
description: Weekly and monthly uptime reports with period-over-period trends, MTTR/MTBF, type-aware sections and insights — by email, dashboard, API, MCP and A2A.
canonical: https://watchfor.io/docs/reports
---

# Uptime reports in WatchFor

Weekly and monthly uptime reports with period-over-period trends, MTTR/MTBF, type-aware sections and insights — by email, dashboard, API, MCP and A2A.

WatchFor reports answer "how did the period go?" in one document: uptime,
incidents, MTTR/MTBF, downtime and response-time trends — always compared
with the equal-length period before, so every number says whether things
got better or worse.

One engine renders every surface, so the numbers can never disagree:

- **Email** — automatic weekly (Mondays) and monthly (the 1st) emails to
  the recipients you choose.
- **Dashboard** — **Reports** in the sidebar, on demand for the last 7 or
  30 days (custom periods and scopes on plans with advanced reports).
- **API / MCP / A2A** — the same document as structured JSON for scripts
  and AI agents; see the [reports API](/docs/api/reports).

## What's in a report

- **Summary** — overall uptime, incident count (with the critical split),
  total downtime, mean time to resolve (MTTR), mean time between failures
  (MTBF) and the longest incident. Every value carries its delta versus the
  previous period.
- **Response time** — fleet average with trend, min/max, and the count of
  checks slower than 1 second. Only latency-style monitor types count here
  — Core Web Vitals audits and heartbeat run durations are excluded so they
  can't skew the average.
- **Monitors** — every monitor with uptime (and its delta), average and
  p95 response time and incident count, sorted worst-first.
- **Insights** — plain-language findings ranked by severity: uptime drops,
  incident concentration ("one monitor caused 7 of 10 incidents"), MTTR
  changes, expiring certificates and domains, Core Web Vitals regressions,
  missed cron check-ins, blocklist listings and MCP tool-inventory drift.
- **Type-aware sections** (advanced reports) — extra sections for the
  monitor types you actually use:

| Section | From monitor type | What it reports |
| --- | --- | --- |
| Locations & latency | any latency-style type | per-location average latency, check success and share of checks |
| SSL certificates | `ssl` | days to expiry, issuer, TLS version, legacy-TLS flags |
| Domains | `rdap` | registration expiry, registrar |
| Core Web Vitals | `browser` | performance score, LCP and CLS trends |
| Scheduled jobs | `heartbeat` | missed/failed check-ins vs total pings |
| DNS blocklists | `blacklist` | listings and the providers involved |
| MCP servers | `mcp` | tool-inventory drift events |

## How the numbers are calculated

- **Uptime** uses the [one formula](/docs/monitors#how-uptime-is-calculated)
  every other uptime figure uses: `(observed − time in confirmed critical
  incidents − scheduled maintenance) / observed`, per monitor (clamped to
  its creation time) and fleet-wide (weighted by each monitor's observed
  time). A failed check that never became a confirmed incident does **not**
  reduce uptime — so the report always agrees with the dashboard and the
  monitor's Uptime SLA tab.
- **Check success** is the **reachability** signal, not a health signal: the
  share of checks where the probe reached the target and got a response,
  per monitor, per location and fleet-wide, with time inside
  [maintenance windows](/docs/monitors/maintenance) that exclude uptime left
  out. A response that then fails a rule — the wrong status code, a failed
  assertion, an expired certificate — counts as *reached* here and shows up
  as an incident instead, so a monitor can be Down at 100 % check success.
  Read it for flakiness and single-location blips: a timeout or a refused
  connection from one city is exactly what it makes visible, without being
  counted as downtime. A monitor with **no checks in the period** (paused,
  or created after it) shows "—" rather than a made-up 100 %; the API and
  CSV carry `null` there.
- **Incidents** marked as [false positives](/docs/alerting/resolving#false-positives)
  are left out of every figure — counts, MTTR/MTBF, downtime and the
  per-monitor column — exactly as on the dashboard and the monitor's Uptime
  SLA tab.
- **Downtime** counts only **confirmed incidents** (the ones that open after
  multi-location confirmation — see [Down vs. Degraded](/docs/alerting/incidents)),
  clipped to the report window, with maintenance overlap subtracted — the
  same rules as the **Uptime SLA** tab on a [monitor page](/docs/monitors#the-monitor-page).
- **MTTR** averages resolve time over incidents that started in the period;
  **MTBF** is the period length divided by the incident count.
- The **previous period** is always the equal-length window immediately
  before — a 7-day report compares against the 7 days before it.

## Plans

Every plan can pull the 7-day and 30-day reports and receive the scheduled
emails. Plans with **advanced reports** add custom periods, monitor and tag
scopes, section toggles, the full monitor table and the full insight list;
on other plans the monitor table shows the ten worst monitors, insights are
capped at two, and locked sections are listed as a one-line summary. The
weekly cadence and the number of email recipients also depend on your plan —
see [pricing](/pricing).

## Custom reports (advanced reports)

The builder on the Reports page lets you compose exactly the report you
need:

- **Period** — last 7 or 30 days, or any custom range up to 92 days.
- **Scope** — pick specific monitors, or tags (a tag scope automatically
  includes monitors you add later with that tag). Useful for per-client or
  per-environment reports.
- **What to include** — toggle the response-time block, the monitor table,
  insights and each type-aware section; the choices adapt to the monitor
  types actually in your selection.
- **Incidents** — count all incidents, or any combination of acknowledged,
  resolved and still-open ones toward the incident numbers (counts,
  MTTR/MTTA, downtime, the per-monitor column); selecting all three is the
  same as **All**. Uptime and check success are unaffected either way —
  uptime always counts every confirmed critical incident.

The same controls exist as query parameters on the API (`from`, `to`,
`monitor_ids`, `tags`, `sections`, `response_time`, `monitors_table`,
`insights`) and on the MCP `get_report` tool.

## Scheduled email reports

Every organization has two email cadences, managed under **Reports → Email
reports** by any owner or admin:

- **Weekly** — sends on Mondays, covering the previous 7 days. **On by
  default** for new organizations, addressed to the owner, so someone always
  gets the weekly picture without any setup.
- **Monthly** — sends on the 1st, covering the previous calendar month. Off
  by default.

Toggle either cadence and edit its recipients (teammates, managers or
clients — recipients don't need a WatchFor account) at any time, up to your
plan's recipient limit. Every change is recorded in the
[activity log](/docs/organization/activity-log).

Every report email carries an **unsubscribe link** (plus the one-click
unsubscribe header Gmail and Yahoo surface natively). An address that opts
out stops receiving that organization's reports permanently — even if it's
added again — and shows struck-through in the recipient list. Reports from
other organizations are not affected.

> **Also via API**
>
> Cadences are `GET /v1/reports/schedules` and
> `PATCH /v1/reports/schedules/{frequency}` on the
> [REST API](/docs/api/reports#scheduled-report-emails), the
> `get_report_schedules` / `set_report_schedule` [MCP tools](/docs/api/mcp),
> and the `manage-report-emails` [A2A skill](/docs/api/a2a).

## Reports for AI agents

The report is a first-class surface for AI agents:

- `GET /api/v1/reports?period=7d|30d` — [API reference](/docs/api/reports)
- MCP tool `get_report` on [the MCP server](/docs/api/mcp)
- A2A skills `org-report` (the full report) and `reliability-report`
  (incident counts by severity, MTTR and a health snapshot) on
  [the A2A server](/docs/api/a2a)
- No-key sample: [`/api/v1/sandbox/reports`](https://watchfor.io/api/v1/sandbox/reports)

All of them return the same structure the dashboard renders — an AI agent
asked "how was our week?" quotes the same numbers a human sees.

---

Canonical page: https://watchfor.io/docs/reports · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt