ObserveifyA percentage needs a denominator
For a time-based measure, uptime is the share of an observation period during which a defined service was available: (period − downtime) / period × 100. A 99.9% target leaves 0.1% of that same period as a downtime budget. The extra nine in 99.99% makes that budget ten times smaller.
Over exactly 30 days, 99.9% allows 43 minutes 12 seconds; 99.99% allows 4 minutes 19.2 seconds. A single 10-minute outage uses about 23.15% of the first budget and more than twice the second. Those are arithmetic examples, not performance claims about any service.
Write down what “available” means before calculating. Does the check only establish an HTTP response, or does it exercise the action a user needs? A successful home page can coexist with a broken sign-in flow. A host being reachable does not establish that its application is usable.
Keep three ideas separate. An indicator is what you measure; an objective is the target you choose. An SLA attaches agreed consequences and conditions to service commitments. A calculator cannot establish those conditions or promise compensation. See Google’s explanation of service-level indicators, objectives and agreements.
Choose the window before reading the result
“Monthly uptime” is ambiguous until you name the month or a fixed duration. February can have 28 or 29 days; other months have 30 or 31. At 99.9%, a fixed 28-day budget is 40 minutes 19.2 seconds and a fixed 31-day budget is 44 minutes 38.4 seconds. The target is identical; the available time differs.
The free uptime calculator uses fixed elapsed durations. Its 365-day and 366-day options handle the two year lengths explicitly. If your report uses calendar boundaries, calculate the actual elapsed duration between those boundaries first, including the chosen timezone, then use custom hours or seconds. A local daylight-saving day can differ from 24 hours; this tool’s “day” always means 86,400 seconds.
A rolling 30-day report and a calendar-month report can include different incidents on the same date. Likewise, a yearly percentage may look healthy even when one month missed its objective. Compare like periods and keep the original start, end and timezone alongside the result.
Count outages without inventing certainty
Use the union of outage intervals for one service. Suppose it fails from 10:00–10:10 and again from 10:05–10:15. That is 15 minutes unavailable, not 20. Clip intervals that cross the report boundary: only the portion inside the observation window belongs in that calculation.
Decide how planned maintenance, partial failures and missing checks are treated, and disclose that policy. The calculator includes all supplied downtime and applies no exclusions. If a contract measures only scheduled service hours, use those eligible hours as the period and count downtime within those same hours. Do not quietly remove downtime while leaving the full calendar denominator.
Monitoring samples are observations, not a continuous recording. A failure beginning between checks has an uncertain start; recovery between checks has an uncertain end. Keep the check interval and your interval-estimation rule with the report. When a monitor was stopped or data is missing, record unknown coverage rather than silently counting it as healthy.
Do not average percentages from monitors with different windows or treat their summed outage minutes as one service’s downtime. First define the customer-facing service and the conditions under which it is unavailable. Request-based success rates also need request counts, rather than the time-based formula used here.
Use a published Uptime Kuma status page carefully
Uptime Kuma’s public status page exposes the monitors its operator chooses to publish. Its official status-page documentation describes caching and periodic refresh, so a public page can lag the dashboard. Check its freshness and reporting window before interpreting a green state as current evidence.
- Use a status page you own or are authorized to read. Review the published monitors; a public page need not represent every component of the service.
-
In ObserveifyNow, open
Connections, choose Uptime
Kuma, and enter the instance base URL and published status-page slug. The default slug
is
default. Do not paste an administrator password into a public-page connection. - In the browser, the service must permit reads from the ObserveifyNow origin. Opening a status page in a tab does not itself establish that cross-origin API reads are permitted. A browser error is not proof of an outage.
- Read the monitor state and its check time. For a historical calculation, obtain complete outage intervals for your chosen window from your own monitoring records, reconcile overlaps, then enter their total in the calculator.
The calculator does not import a status page, probe a URL or reconstruct incident history. A current status snapshot cannot prove a month of uptime. Never expose a protected dashboard, weaken TLS or change access rules just to make a percentage appear.
A repeatable end-of-period review
Imagine one application observed for 30 fixed days with a 99.9% target and 30 minutes of reconciled downtime. The period is 2,592,000 seconds and the downtime is 1,800 seconds. Its calculated uptime is about 99.930555556%, leaving 13 minutes 12 seconds of the target budget. Against 99.99%, the same incident history exceeds the budget by 25 minutes 40.8 seconds.
For your own review, record the service definition, window, timezone, target, data source, coverage gaps and exclusion policy. Total the relevant outage intervals, calculate once, and save the local text result alongside those records. The download contains the supplied durations and formulas; it is not a monitoring export or independently verified report.
If the observed result misses the target, inspect which incidents consumed the budget and which user actions failed. A useful next action might be a recovery test or a better check of a critical dependency. Changing the denominator after seeing an unfavorable result does not improve reliability.
What ObserveifyNow can read today
ObserveifyNow is a device-first, read-only infrastructure console. Reading and local connection management are free without an account. The browser reads published Uptime Kuma status pages when the service allows the browser origin. Protected Proxmox VE, Proxmox Backup Server and Beszel reads require the native app.
Infrastructure connections and metrics stay on the device; they are not relayed to an account service or collected as cloud analytics. Android has foreground status-change notifications and a last-summary widget. Background checks, iOS widgets, an iOS release and store downloads are not available. Native distribution remains in development; this guide does not establish packaged-device or live-provider validation.
Use the product overview for current availability, connection help for setup boundaries and data handling for local storage and optional-account details.