Assess hosting availability by defining a useful service operation, measuring its success over a stated period and comparing the result with the applicable objective or agreement. A server answering a ping is not proof that checkout, login or an API works. No security bundle guarantees 99.99% availability for every application.
WebCare360 publishes this guide and sells hosting. This is a method for creating an availability record, not a report of WebCare360 uptime or a new service-level commitment.
Define the indicator, objective and agreement
Google's SRE guidance on service-level objectives distinguishes the measurement (SLI), its target (SLO) and an agreement with consequences (SLA). It also explains why user-relevant measurements and their aggregation matter. Use those distinctions without importing another organization's targets into your service.
Write a measurement definition before choosing a percentage. Specify the user operation, success condition, eligible population, observation point, measurement interval and review window. For example, a successful application response might require a valid result within a workload-specific deadline; merely receiving HTTP 200 may not prove the intended operation completed.
Calculate from a consistent denominator
Illustrative request-based measurement:
Successful eligible operations / all eligible operations × 100
99,850 / 100,000 × 100 = 99.85%This is arithmetic, not a hosting test result. A request-based ratio differs from measuring the fraction of time a service is usable. Do not convert between them without understanding traffic distribution, probing frequency and missing observations. A service with no observed requests does not produce evidence of perfect availability.
Keep the counts and query or report definition with the result. Record missing telemetry rather than silently counting it as success. Separate measurement gaps, planned exclusions and observed failures so a later reviewer can reproduce the calculation.
Check whether the measurement represents users
Use representative operations and locations. A public cached page can work while authenticated application requests fail; a test from one region can miss a fault affecting another. Avoid hiding a critical operation inside a large total of unrelated successful requests.
Compare external observations with application and infrastructure records for the same time window. Document clock, sampling and retention limits. Synthetic probes exercise their configured path; real-user or request data has its own coverage and privacy constraints. Neither automatically supplies a complete view.
Map failures to dependencies
| Observed failure | Check the relevant boundary |
|---|---|
| Hostname cannot resolve | Domain status, DNS configuration and authoritative service |
| Connection or TLS fails | Network path, listener, certificate and proxy |
| Application returns an error | Deployment, runtime, database and external APIs |
| Operation is too slow | Application work, resource pressure and downstream response times |
| Data is missing after recovery | Recovery point, restore procedure and consistency checks |
These are investigation directions, not diagnoses. More capacity does not repair every dependency failure. A second machine is not proof of tested failover, and a backup does not keep an application continuously available.
Compare the record with the actual SLA
If a contractual SLA applies, read its covered service, measurement method, period, exclusions, claim procedure and remedy. Keep your application indicator separate where its scope differs. A service credit is a contractual remedy, not evidence that the business impact was prevented or fully compensated.
Use WebCare360's current service agreement and the accepted order for applicable terms. Check the measurement window, exclusions and claim process in those terms before applying an uptime figure to a service claim.
Turn the finding into an operating action
Record the observed result, affected journeys, dependency evidence, responsible operator and corrective action. Validate a change against the same measurement definition and keep a rollback plan. Review recovery evidence separately from uptime. For a documented traffic-flood risk, evaluate DDoS protection scope; it does not cover every cause of failure.
The outcome should be a repeatable measurement with known limits and an assigned response. A favorable percentage for one period is useful evidence about that period, not a promise that future interruptions are impossible.
