Detailed Logs filters help reduce a large check history to the observations relevant to one problem. Filters are combined, so a row must satisfy every applied condition.
Apply filters deliberately
Changing a field does not immediately replace the current table. Choose all the conditions you need, then select Apply.
This keeps the existing result set and page controls usable while you prepare a different query. The summary cards, page count, table, and CSV export update only after Apply succeeds.
Select Reset to return to:
- Last 24 hours.
- All statuses.
- All diagnosis categories.
- No HTTP, error-text, or latency limits.
- 100 rows per page.
Status
Choose:
- All for successful and failed checks.
- Up only for checks that Uptime Basics accepted as successful.
- Down only for individual failed checks.
Down only does not mean confirmed incidents only. A failed row can be present even when regional or consecutive confirmation prevented the monitor from changing to Down.
An HTTP status of 400 or higher can appear under Up only if that status was explicitly configured as acceptable for the monitor.
Diagnosis
Diagnosis matches one normalized failure category exactly. Available categories include blocked, authentication required, method not allowed, rate limited, timeout, DNS, SSL/TLS, redirect loop, server error, client error, and unknown.
Successful checks normally have no failure diagnosis. Choose a diagnosis together with Down only when investigating a particular type of failure.
Diagnosis is a troubleshooting classification, not proof of the external system's root cause. Open the incident or compare the Error and Confirmation columns for more context.
HTTP code
Enter one exact numeric HTTP response, such as 403, 429, or 500.
The field does not interpret groups such as 4xx, lists, or ranges. A timeout, DNS failure, or TLS failure can have no HTTP code because the request did not receive an HTTP response.
Examples:
- Down only + HTTP 500 finds failed checks that returned exactly 500.
- Up only + HTTP 401 can reveal a 401 configured as acceptable.
- HTTP 403 + Blocked narrows the result to rejected monitoring requests classified as blocked.
Search error
Search error performs a case-insensitive text match inside the stored Error value. A partial term such as timeout, certificate, or fetch failed can match longer messages.
This search does not search the monitor name, URL, diagnosis label, failure reason, or recommended action. Use their dedicated fields or inspect the matching rows and CSV export.
Minimum and maximum latency
Latency filters use milliseconds and include their boundary values:
- Minimum 1000 includes checks at 1000ms and above.
- Maximum 500 includes checks at 500ms and below.
- Minimum 500 and maximum 2000 creates an inclusive 500-2000ms window.
A positive minimum excludes checks without a recorded response duration. A maximum-only query can still include transport failures with no latency value, so inspect the Latency column before interpreting the count.
Latency measures the monitoring HTTP request. It is not browser rendering time or a Core Web Vitals measurement.
Build useful combinations
Try these starting points:
| Question | Suggested filters |
|---|---|
| Which checks failed? | Down only |
| Was the server returning errors? | Down only + Server error |
| Did bot protection reject checks? | Down only + Blocked + HTTP 403 |
| Which successful requests were slow? | Up only + a meaningful minimum latency |
| Were failures timeouts rather than HTTP errors? | Down only + Timeout |
| Did rate limiting occur? | Down only + Rate limited + HTTP 429 |
Start broad, then add one condition at a time. If no rows remain, remove the most specific condition before assuming the data is missing.