The Activity Log puts check observations, notification activity, and system events on one incident timeline. Use it to reconstruct what Uptime Basics observed and when, without treating notification delivery as part of the uptime result.
Filter the timeline
Use the buttons above the log to focus on one kind of evidence:
| Filter | What it shows |
|---|---|
| All | Checks, alerts, and system events together. |
| Checks | Successful and failed checks observed during the incident. |
| Alerts | Outage, recovery, slow-response, SSL-expiry, or domain-expiry notifications and their delivery states. |
| System | Incident lifecycle events such as resolution. |
Changing a filter does not change the incident or rerun monitoring. It only changes the events displayed.
Expand grouped events
Repeated events are grouped to keep long incidents readable. A group can represent several similar failed checks or notification records within a short period.
Expand a group to inspect its individual timestamps and details. Grouping does not mean only one check occurred, and it does not change the incident duration or uptime calculation.
Read check activity
A check entry can include an HTTP status, response time, or normalized failure reason. Use it to answer questions such as:
- Did failures continue after the incident opened?
- Did the target alternate between successful and failed responses?
- Did the HTTP result or error category change?
- Which successful check coincided with recovery?
The activity description is a concise observation. Open Checks Around Incident or Detailed Logs for more check fields.
Read alert activity
Alert entries identify the notification type and delivery state. For example, an outage email can be queued, sent, delivered, failed, bounced, rejected, or suppressed.
The alert timestamp can be later than the check or incident timestamp because delivery is asynchronous. A failed or suppressed notification does not change the incident status.
Understand long-incident limits
For long incidents, the Activity Log uses bounded evidence from the beginning and end of the incident rather than loading every raw event in the middle. Similar events are also grouped.
This keeps the page responsive, but it means the Activity Log is not a complete raw-check ledger. Use Detailed Logs for all retained checks in a selected range.
Why an older incident can have a shorter log
Incident history remains for the life of the monitor, but raw checks are retained for 30 days and Alert History for 14 days. As those supporting records expire, the incident can remain while some activity entries are no longer available.
All timestamps use the time zone selected in Account settings.