Check logs - Tallwatch Documentation

Every region check Tallwatch runs is stored as a row. The Logs tab on a monitor lists those rows newest first so you can see what each probe saw over time, not only when an opens. Open a monitor in the , then choose Logs.

What each row shows

Field	Meaning
Time	When that region finished the check
Region	Probe label (or `heartbeat` for push monitors)
Status	`up`, `down`, or `degraded`
HTTP code	Present for HTTP paths that got a response
Latency	Total duration, with a phase bar when DNS / connect / TLS / TTFB / transfer were measured
Detail	Failure message, allowlisted response headers, and a capped body sample when the check failed or degraded

Healthy checks stay lean on purpose: headers and body samples are kept on fail paths, not on every green 200. That keeps storage and privacy bounded while still answering “what did the origin return when it broke?”

Filters and retention

Filter by status or region. Pages use cursor pagination (same pattern as other Tallwatch lists). Raw check rows are kept for about 30 days. Longer charts use five-minute rollups on the Overview tab, not the Logs list.

Logs vs incident evidence

Surface	Answers
Logs	What did each probe see over time?
Incident evidence	Why did we page for this outage?

Evidence freezes the regional votes and probe facts at open. Logs are the continuous history. Use both; they are not the same screen.

API and MCP

GET /api/v1/monitors/:id/checks — list (no full response_meta)
GET /api/v1/monitors/:id/checks/:checkId — one check including failure meta
MCP: list_monitor_checks, get_monitor_check