A newly created monitor is displayed as Pending while it waits for its first completed check. Its underlying availability remains unconfirmed, and its average response, p95 response, total checks, response chart, and Uptime Timeline can remain empty until the first scheduled request is completed and stored.
The service does not label a monitor Up merely because its configuration was accepted.
What happens after creation
- Uptime Basics validates and stores the monitor configuration.
- The scheduler identifies it when it becomes due.
- A worker performs the configured HTTP or HTTPS request.
- The result is stored as a raw check and added to summary rollups.
- The dashboard or Monitor Details requests the updated state.
The configured interval is a scheduling frequency, not a promise that the first result will be visible immediately after creation.
First successful check
The first successful result changes a new active monitor from Pending to Up. Summary metrics then begin using the available check history.
With only one or a few checks:
- Availability is valid but represents very little history.
- Average and p95 can be the same.
- The timeline contains only the periods observed since creation.
- Empty earlier blocks do not mean downtime.
First failed check
A first failure does not immediately mark a new monitor Down. To reduce false alarms, Uptime Basics requires three consecutive failed cycles that also satisfy regional confirmation.
Until that confirmation is complete:
- The overall monitor state can remain Unknown.
- Detailed Logs can already contain failed checks.
- Availability for the selected range can reflect those failures.
- A confirmed incident might not exist yet.
This is intentional. Check history records observations; current status applies outage-confirmation policy.
How long to wait
Allow at least:
one configured interval + request timeout + normal processing and page refresh time
If the endpoint is failing, allow enough time for three scheduled confirmation cycles. Regional requests and timeouts can add processing time to each failed cycle.
For example, a five-minute monitor that cannot connect may remain Unknown longer than five minutes while failed cycles are collected and confirmed.
Why the selected range can look empty
Confirm that:
- The monitor is Active rather than Paused or Archived.
- The selected range includes the monitor's creation time.
- Detailed Logs have no restrictive status or diagnosis filter applied.
- The account dashboard's Last update indicator is current.
- No automatic-protection notice is displayed.
Monitor Details uses rollups when available and recent raw checks as a fallback. It shows no data when neither source contains an applicable check; it does not manufacture a healthy result.
When there is a problem
Investigate when an Active monitor remains without check rows for more than one expected interval plus its timeout and normal processing time.
Before contacting Support:
- Open Detailed Logs and reset the filters to Last 24 hours and All statuses.
- Confirm the exact monitor URL, interval, request method, and timeout.
- Check for an account-wide service notice.
- Record the monitor creation time and dashboard Last update value.
- Avoid deleting and recreating the monitor, because that removes useful configuration and troubleshooting context.
Contact Support if multiple expected checks remain missing. Do not send passwords, verification codes, or secret authorization headers.