Availability is the percentage of monitoring checks that succeeded during a selected time window. It measures observations made by Uptime Basics; it is not a guarantee that every visitor could reach the website for every second of that period.
Availability formula
Uptime Basics calculates availability as:
successful checks / total checks x 100
For example, 999 successful checks out of 1,000 total checks produce 99.9% availability.
Each completed scheduled check has equal weight within that calculation. The amount of time between checks is not converted into continuous second-by-second availability.
What counts as a successful check
A check is successful when the monitored HTTP or HTTPS endpoint responds within the timeout with:
- An HTTP status below 400; or
- An additional 400-599 status code that you explicitly configured as acceptable.
The request must also complete after any enabled redirects and pass the monitor's destination-safety rules.
What counts as a failed check
A failed check can include:
- A request timeout.
- A DNS, connection, TLS, or HTTP transport failure.
- An HTTP status of 400 or higher that was not configured as acceptable.
- A redirect error, unsafe redirect destination, redirect loop, or chain beyond the supported limit.
A slow but successful response remains an Up check if it finishes within the availability timeout. Slow-response alerts are calculated separately.
Why availability and incidents can differ
Availability uses individual check outcomes. Incident creation uses confirmation rules designed to reduce false alarms.
This means:
- One failed check can lower availability while the monitor remains Up.
- Availability can be below 100% while the dashboard shows zero incidents.
- An incident opens only after the consecutive-failure and regional-confirmation requirements are met.
- Recovery requires healthy evidence after a confirmed outage.
Use Detailed Logs to investigate individual failures and the incident page to understand confirmed state changes.
Dashboard availability
The main dashboard combines successful and total checks from all account monitors in seven UTC calendar-day buckets: the current UTC day and the previous six days.
This is a check-weighted result, not a simple average of monitor percentages. For example, a one-minute monitor contributes about five times as many scheduled results as a five-minute monitor over the same active period.
Paused monitors do not create new checks. Their earlier results remain in the dashboard calculation until those result buckets leave the seven-day window. Archived or deleted monitors also do not create new results; previously recorded account-level results can remain in the historical window while it rolls forward.
Monitor Details availability
Monitor Details calculates the percentage for one monitor and the selected range:
- 24 hours.
- 7 days.
- 1 month.
- 1 year.
Short ranges can use individual check data when a rollup is not available. Longer ranges use aggregated rollups that preserve successful and total check counts without loading every raw record.
Raw check logs are retained for 30 days, while rollups are retained for up to 400 days. This is why the one-year availability view can remain available after its individual checks have expired.
No data and new monitors
A new monitor begins as Unknown and does not receive an availability percentage until at least one check result is available. A dash means there are no applicable check results for that range; it does not mean 0% or 100%.
A percentage based on a small number of checks is mathematically valid but has limited history. Review the total-check count and selected range before drawing a reliability conclusion.
Display precision
Dashboard and monitor summaries display availability to three decimal places. Rounding can show 100.000% when the unrounded value is extremely close to 100%. Use the underlying check totals and logs when exact failed-check counts matter.
Availability is not the same as an SLA
The percentage describes results observed by the service from its monitoring infrastructure. It does not account for every user location, visual page rendering, JavaScript behavior, application transactions, or periods outside the selected window.
Define any contractual service-level commitment separately, including its measurement source, exclusions, maintenance policy, and calculation rules.