Use Detailed Logs CSV when you need individual retained checks, and use an incident JSON export when you need the evidence associated with one confirmed incident. Charts and long-range rollups are better for trends but are not a substitute for raw check rows.
Choose the source that matches the question you are trying to answer before exporting or calculating results.
Choose the right data view
| Question | Best source |
|---|---|
| What is the monitor's current state? | Dashboard or Monitor Details |
| Which individual checks failed in the last 30 days? | Detailed Logs |
| What happened around one confirmed incident? | Incident Details and incident JSON |
| Was a notification queued or delivered? | Alert History or incident activity |
| What was the availability or response-time trend over months? | Monitor Details rollup views |
| Do I need a spreadsheet-ready retained check set? | Detailed Logs CSV |
Raw checks are retained for 30 days. Daily and hourly rollups support longer monitor charts for up to 400 days, while incident records remain for the lifetime of the monitor. A deleted monitor is recoverable for 30 days before permanent cleanup of its associated monitoring data begins.
Export checks to CSV
- Open the monitor.
- Open Monitor Tools, select Detailed Logs, and then select Open detailed logs.
- Choose Last 24 hours, Last 7 days, Last 30 days, or a valid custom range.
- Add the status, diagnosis, HTTP, error, or latency filters you need.
- Select Apply.
- Confirm the Matching rows value.
- Select Export CSV.
The export contains the complete applied filtered result set, not only the visible page. Unapplied filter changes are not included.
Exports are limited to 50,000 matching rows. The browser retrieves them in batches of up to 500 and shows progress. Narrow the range or filters if the result exceeds the limit.
Interpret CSV columns
| Column | Interpretation |
|---|---|
timestamp |
Check time in ISO 8601 UTC |
status |
Result of this individual check: up or down |
http_code |
HTTP status when a server returned one |
latency_ms |
Recorded availability-request duration in milliseconds |
failure_category |
Normalized diagnosis for a failed request |
confirmation_summary |
Regional confirmation outcome when the primary check failed |
failure_reason |
Customer-facing explanation of the observed failure |
recommended_action |
Suggested next troubleshooting step |
error |
Stored request error when available |
url |
URL associated with that check |
An empty field means that the value was unavailable or not applicable. It does not mean zero. For example, a DNS failure occurs before HTTP and therefore normally has no HTTP code.
Individual Down rows are not incidents
A down CSV row represents one failed check. It does not prove that the monitor reached the confirmed Down state or that an incident opened.
For availability incidents, Uptime Basics requires:
- at least two of three monitoring regions to fail the check cycle; and
- three consecutive region-confirmed failed cycles.
Use confirmation_summary and the Incident Details page when deciding whether several failed rows became a confirmed outage.
Likewise, the incident start time is the confirmed Down transition, not necessarily the timestamp of the first failed row.
Interpret response time correctly
latency_ms measures the monitored HTTP request. It is not a browser page-load score and does not include rendering, JavaScript execution, images, fonts, user interaction, or every downstream request made by a webpage.
When comparing response time:
- compare the same URL, request method, region policy, and time period;
- separate successful requests from failures;
- investigate isolated spikes before treating them as a sustained problem;
- use average for a broad baseline and p95 for slower-edge behavior; and
- use Slow Response incidents when you need confirmed performance alerting.
A timeout can have a recorded duration but no HTTP code because the request ended before an HTTP response was available.
Calculate availability from a CSV
For an unfiltered export containing all retained checks in the selected period:
availability percentage = up rows / all rows * 100
Do not use a Down-only, Up-only, diagnosis-filtered, or latency-filtered export to calculate overall availability. The filtered dataset intentionally excludes checks.
Your calculation can also differ from a long-range Monitor Details percentage when:
- the periods do not match exactly;
- raw checks have expired;
- the monitor was paused or archived;
- the chart uses stored rollup buckets; or
- your spreadsheet removes or modifies rows.
Use the Monitor Details value as the product's displayed calculation for its selected range.
Read diagnosis and confirmation together
The diagnosis describes the best available category for the failed request, such as timeout, DNS, SSL, blocked, rate limited, redirect loop, or server error.
Regional Confirmation describes whether other monitoring locations reproduced the primary failure. It does not identify the website's internal root cause.
For example:
- Blocked plus failures in multiple regions suggests a broader WAF, firewall, bot, or access-policy rejection.
- Timeout in only the primary region can indicate a route-specific or intermittent problem.
- DNS failures in multiple regions are stronger evidence of public DNS trouble than one local cached browser result.
- Every diagnostic layer later passes can mean the website recovered before incident diagnostics ran.
Correlate these fields with your own DNS, CDN, firewall, hosting, server, deployment, and application logs from the same time.
Export one incident as JSON
Open Incident Details and select Download incident data when you need one incident's structured evidence.
Depending on availability and retention, the JSON can contain:
- monitor and incident details;
- request and response summaries;
- regional confirmation;
- DNS, TCP, TLS, and HTTP diagnostics;
- grouped activity;
- a bounded sample of nearby checks; and
- bounded alert records.
The incident export does not rerun the monitor or collect new diagnostics. Use Detailed Logs CSV for the full applied raw-check result set still within retention.
Protect exported files
CSV cells are quoted and values beginning with spreadsheet formula characters receive a protective prefix. Saved Basic Authentication passwords and custom-header secret values are not exported.
Exports can still contain operationally sensitive URLs, public diagnostic IP addresses, timestamps, errors, and availability patterns. Review a file before sharing it, limit access, and apply your organization's storage and deletion rules.
A downloaded copy is not automatically removed when Uptime Basics retention expires, the monitor is deleted, or the account is closed.