Uptime monitoring
Track availability, response times, and incidents for a Screpy project website.
Uptime monitoring checks whether the project website is reachable over time. It answers a different question from a crawl or a Core Web Vitals check: availability asks whether users can reach the site; performance asks how the page behaves once it loads.
The Uptime view displays the current status, 30-day uptime, average response time, and last check. It also shows the monitoring interval available on the current plan, a response-time timeline, persisted recent checks (status, timestamp, HTTP response, and response time), and open or resolved incidents.
Interpret an uptime event carefully
Start with the time, target, and recent checks. A single failed check can be caused by a short deployment, DNS change, TLS issue, origin outage, firewall rule, or a temporary provider problem. Repeated failures or a sustained outage deserve escalation; isolated events should be checked against hosting and deployment logs before declaring an incident.
Make sure the monitored project URL represents a useful public path. A protected admin route, a page that intentionally redirects, or a URL that is only available from a private network is not a reliable uptime target for visitors. Enable or adjust the monitoring interval in Project settings; the allowed interval is plan-dependent.
Use incidents to improve reliability
When an outage occurs, record what changed, how long the service was unavailable, and how it was resolved. Then decide whether a monitoring threshold, deployment check, DNS setting, health endpoint, or operational runbook needs improvement. The goal is not only to restore the site, but to reduce the chance and duration of the next incident.
Common questions
Why does the site work for me but show a failed check?
Compare the monitored URL, response behavior, DNS, certificate, and any IP or user-agent restrictions. A local browser can use a different cache, location, or network path than an external monitor.
Is a redirect downtime?
Not necessarily. What matters is whether the redirect reaches the intended public destination reliably and without an unexpected loop or error.
Why is the most recent check older than expected?
Check whether uptime is enabled for the project, whether the plan interval has changed, and whether the target remains publicly reachable. The interval shown in the Uptime view is the correct expectation for that project.
For the exact scope and limits of an availability result, see how Screpy measures uptime.