Skip to main content

How free service-status checks and Recent History work

Learn how often free service pages are checked, how Down is confirmed, what Recent History shows, and how long the data is retained.

Free service-status pages check one selected public HTTP or HTTPS URL every 15 minutes. The page combines the latest confirmed status with a small sample of individual check results.

The page is an independent external observation. It does not inspect every product component, geographic region, account, application, or internal system operated by the service provider.

Current Status

The Current Status pill can show:

  • Pending while the first completed checks are being collected;
  • Up after a successful check;
  • Down after three consecutive failed checks confirm the change; or
  • Unable to verify when the monitored site rejects the monitoring request, so an independent check cannot confirm its availability;
  • Disabled when Uptime Basics has intentionally stopped scheduling checks.

A successful check recovers a confirmed Down state to Up. The latest check time shows when the displayed monitoring result was performed, not when the visitor opened the page.

Free service pages use one independent external monitoring path. They do not use the paid-monitor multi-region confirmation process.

What one check tests

Each scheduled check requests the public URL shown on the page. Uptime Basics:

  • starts with an HTTP HEAD request;
  • can retry with GET when the endpoint rejects a header-only request;
  • follows ordinary redirects, up to the monitoring redirect limit;
  • applies a bounded request timeout; and
  • records the availability result, HTTP response code, response time, and a high-level diagnosis.

The result describes the selected URL. A successful homepage or public endpoint does not prove that every login, API, geographic region, or customer account is working.

Why a failed row may not change Current Status

Recent History contains individual check results. Current Status is a confirmed state.

One or two failed rows can therefore appear while the Current Status remains Up. This means Uptime Basics observed a temporary failure but did not yet receive the three consecutive failures required to label the service Down. If the site rejects the monitoring request, the page instead shows Unable to verify; that result does not confirm an outage.

Similarly, a new page can have failed rows while it remains Pending until the initial Down state is confirmed.

How Recent History is sampled

Uptime Basics retains free service-page check records for 24 hours. The page loads a bounded group of the newest checks, then displays every fourth result, up to 10 rows.

With checks scheduled every 15 minutes, every fourth result represents approximately one result per hour. Ten displayed rows provide roughly ten hours of recent context without loading a large table on every visit.

Recent History includes:

Column Meaning
Time When the check ran, displayed in the visitor's browser time zone
Status The individual check result, Up or Down
HTTP The returned HTTP response code, when one was received
Latency The measured response time in milliseconds
Diagnosis A high-level failure category, when available

A timeout or DNS/TLS connection failure may not have an HTTP code because no HTTP response was received.

Cached updates

The page normally loads a small CDN snapshot, with the public API as a fallback. Public status responses can be cached for about 60 seconds, so a completed check may not appear on every browser at exactly the same instant.

If both live sources have a temporary server or network failure, the page can use a valid snapshot saved in the current browser session for up to 30 minutes. When this happens, showing a cached update appears beside the last check time.

Unavailable means the page data could not be loaded. It does not mean the monitored service is Down.

What Recent History does not provide

The free page is not a long-term service-level report. It does not provide:

  • 30-day or yearly uptime commitments;
  • a complete provider incident history;
  • internal component status;
  • account-specific or regional guarantees; or
  • automatic alerts for visitors.

For automatic alerts and longer customer-monitor data retention, create a monitor in a paid Uptime Basics account.

Related articles

Did this answer your question?

Your response helps improve this Help Center.