On-demand availability and uptime budget check
Run repeated checks against a public URL, decide what counts as an available response for this run, read success rate and latency stability, then compare the result with uptime targets and downtime budgets before you move to scheduled monitoring.
This page runs a live snapshot from the PeopleAreGeek backend. A real uptime monitor adds a schedule, multiple regions, alert routing and history across time.
What this uptime checker measures
Uptime sounds like one number, but an operator usually starts with a run log. Did the URL answer repeatedly? Which HTTP statuses came back? Were the checks consistently fast enough to feel healthy, or did one probe take several times longer than the others? This uptime checker is built for that first pass. It samples a URL several times, measures the result set and lets you choose whether this probe should accept only successful 2xx responses, tolerate redirects, or treat any non-server-error response as an answer.
That policy matters. A homepage that quietly becomes a 404 is not “available” in the useful sense even if a web server answered. An API health endpoint may need a strict 200. A migration probe can reasonably count a deliberate redirect while redirect rules are being checked elsewhere. The tool keeps the policy visible so the result is not a mysterious percentage.
Manual checks and real monitoring are different jobs
An on-demand uptime test is useful after a deployment, host migration, plugin change, firewall rule, DNS change or suspicious support message. It gives you evidence now. Scheduled uptime monitoring gives you evidence over time. It can detect outages while nobody is looking at the page, preserve incident history, alert the right person and compare regions or networks. Use this page for diagnosis and calibration, then monitor critical services continuously.
How to read success rate and latency together
A perfect success rate with unstable latency still deserves attention. Slow first responses can be the beginning of queueing, overloaded PHP workers, database pressure, cache misses or upstream trouble. One outlier does not prove an outage, but a wide spread across a short run is worth saving in the report and comparing later.
- Success rate shows how many runs met the selected response policy.
- Status set reveals whether the endpoint behaved consistently.
- Average, fastest and slowest give a quick latency envelope.
- Spread shows how far the slowest run drifted from the fastest one.
- Run log keeps every status and time visible instead of hiding the evidence behind one score.
Uptime target and downtime budget
An uptime target becomes real when you translate it into time. A target of 99.9 percent leaves a much smaller monthly budget than 99 percent. A stricter target also needs an operating habit behind it: monitoring, alert ownership, maintenance planning, incident review and dependencies that fail gracefully. The budget table here is a planning aid. It does not turn eight good checks into a monthly SLA result.
For a small WordPress site, the practical takeaway is simple. Important pages should answer reliably after routine changes. If a run finds failures, fix status and availability first. If the run is available but slow or unstable, inspect caching, server load, heavy plugins, redirects and third-party calls before promising a stronger uptime target than the setup can support.
A useful uptime troubleshooting routine
- Probe the exact public URL users or integrations rely on.
- Use the strict response policy that matches that URL role.
- Keep the run log when status changes or latency spread is large.
- Check website status, redirects, SSL and headers when the failure path is not obvious.
- Add scheduled monitoring for pages and endpoints where a missed outage matters.
Common questions
Is this the same as a status checker?
No. The status checker explains one response path in detail. This uptime checker focuses on repeated availability samples, response policy and downtime budget context.
Should redirects count as uptime?
Only when that matches the probe purpose. For a canonical public page, test the final URL directly. For an old URL during migration, a deliberate redirect may be part of the intended behavior.
Can this prove a 99.9 percent SLA?
No. A short manual run cannot replace scheduled measurements over the full reporting period. It can show whether the endpoint looks healthy right now.
What does 99.9 percent uptime actually allow?
About 43 minutes of downtime per month, or 8.7 hours per year. 99.99 percent allows only about 4 minutes per month. Each extra nine is much harder and costlier to reach.
How often should I poll for uptime?
Every one to five minutes is a good balance: frequent enough to catch short outages, infrequent enough to avoid hammering the server or triggering rate limits.
Why does my site flap between up and down?
Intermittent results usually mean an overloaded server, a flaky upstream, DNS instability, or aggressive rate limiting. Correlate the dips with server load and logs.
