Revenue websites
Keep the storefront, booking site, subscription product, or lead-generation website under recurring external availability checks.
Website Uptime Monitoring with Alerts
Monitor your project's public URL, review 30-day availability and response times, and investigate failed HTTP checks. Keep incident history and qualifying email alerts alongside your SEO work.
Configure Website Uptime Checks
Enable recurring availability checks for the public URL saved in your Screpy project. Choose a useful visitor-facing target before deciding how often to check it.
- Each project monitors one configured HTTP or HTTPS URL, not a separate list of endpoints.
- Project settings control monitoring, a 1–60 minute interval and an optional notification email.
- Scheduled checks require an eligible active paid plan; plan defaults vary.
- Intervals become longer after project-team inactivity, and checks stop after 30 inactive days.
- Read Last Check to confirm freshness; the configured interval is not an exact delivery guarantee.
example.com60 s
Understand Website Uptime Percentage
See how often the monitored URL responded successfully in the last 30 days. Read the percentage alongside the check count and latest timestamp.
- Uptime equals successful checks divided by all recorded checks, multiplied by 100.
- Current Status comes from the latest completed check in that window.
- No recorded checks means unavailable data, not 100% uptime.
- The percentage is sample-based; it cannot be converted directly into outage minutes or a time-weighted SLA.
Uptime
93.8%503200
Track Website Response Times
Use the response timeline to spot slower checks and repeated failures. A reachable URL can still respond slowly, so status and latency answer different questions.
- The chart uses recent checks, up to 160 within 30 days; the visible subset depends on screen width.
- The trend line averages five checks; Avg Response uses successful checks across the full 30-day window.
- Times measure HTTP response latency, not full page loading, Core Web Vitals or a visitor journey.
Response time
240 msReview HTTP Status Checks
Inspect the eight latest checks with status, time, HTTP code and response time. Compare these records with what your public URL is expected to return.
- HTTP 200–399 counts as up; other HTTP responses count as down, with timeout and error recorded separately.
- Redirects are not followed: a 3xx result does not confirm that the destination works.
- Checks use HEAD, retrying with GET on 405 or 501; connection failures may have no HTTP code.
- An up result does not verify page content, forms or checkout; even an error page served as HTTP 200 can count as up.
HTTP status
200GET /HTTP/2 200Review Website Downtime Incidents
Follow an outage from its first failed check to a later successful check. Keep the incident record separate from the investigation into why the website failed.
- The first failure opens an incident; repeated failures update it, and the first successful check resolves it.
- The dashboard shows all-time open and resolved counts plus the five latest incidents with status, start time and details.
- Recorded incident times reflect checks, not exact failure onset between checks; brief outages may be missed.
Period
12 min503200
Receive Downtime Emails
Send qualifying outage notices to project members and an optional additional inbox. Incident recording starts before an email becomes eligible.
- A later failure during the same incident can trigger email for supported HTTP codes such as 404, 500 or 503.
- Timeouts, connection errors and unsupported HTTP codes are recorded but do not trigger these outage emails.
- Each project has separate limits of one outage email and one recovery email per 24 hours.
- Recovery email requires a previously notified, unsuppressed incident; its recorded duration does not establish exact visitor downtime.
!
Projectexample.com
ReviewRead Uptime Data Through SEO MCP
Ask a connected AI assistant to explain saved availability results for a project you can access. Use timestamps to distinguish recorded evidence from a new check.
- SEO MCP returns the 30-day status, uptime percentage, successful-check average and last check.
- Up to 160 recent records include status, response time and timestamp; this summary omits HTTP codes and incident records.
- The read-only request neither runs a fresh check nor identifies or fixes an outage; missing results stay unavailable.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Add Uptime to SEO Reports
Include availability evidence in a saved SEO report for a client or team. A report snapshot answers a different question from a live monitoring screen.
- The uptime widget includes 30-day check statistics, recent checks and incidents overlapping that reporting window.
- Report incident counts can differ from the dashboard's all-time counts; resolved incidents can include their recorded duration.
- The report captures saved data at generation time and does not send live outage alerts.
Sections
aACMEReportPDF
Health score87/100
Position+24
Talk about Uptime Monitoring. With SEO MCP.
Use SEO MCP to read a saved project's 30-day uptime summary and recent status/response records. Check the timestamp before treating the latest recorded status as current availability; this response has no incident list or HTTP codes.
- Screpy: Hello! Let’s look at Uptime Monitoring for example.com. What would you like to know?
- You: Explain the saved uptime summary and last-check time for example.com.
- Screpy: Illustrative saved result: the last check at 10:18 UTC recorded up, with 99.95% successful checks over 30 days. That percentage is check-based. It does not prove the site is reachable now; use dashboard incidents and hosting logs for an outage investigation. Saved uptime summary: Last check: 10:18 UTC. 30-day uptime: 99.95%.
- You: Turn that into a short action plan.
- Screpy: I’ll keep the evidence and recommendations separate. Review the findings, choose one change and check the results afterward. Your next steps: Review: Check the source and date of each finding.. Decide: Choose the first change to make.. Verify: Compare the results after the change..
- You: Can you explain the evidence in plain language?
- Screpy: Yes. Ask about a supported result and I can explain what it shows, where it comes from and what is still uncertain. Missing data stays unavailable; recommendations are not automatic fixes.
Set up a useful uptime monitoring loop.
Choose a meaningful public target, enable monitoring and route qualifying email to a responsible inbox. When a check fails, investigate the current records and confirm a later successful check.
-
Use the public project website URL
Use the project's intended public URL. Avoid login-only paths; check redirect destinations separately because uptime checks do not follow redirects.
-
Enable checks and configure the interval
Enable monitoring in Project settings, save the interval and optional notification email, and confirm eligible paid access and recent check activity.
-
Investigate the latest failed checks
Read current status, last check, recent HTTP outcomes and incident details. A critical failure deserves investigation now; the 30-day percentage provides context, not a reason to wait.
-
Investigate and confirm recovery
Compare the recorded failure with deployment, DNS, TLS, hosting and application logs. Confirm a later successful check; incident resolution alone does not verify every visitor path.
Prioritize websites where downtime carries real cost.
Use recurring checks for projects where availability affects sales, leads, campaigns, customer access, or the ability of search crawlers to retrieve public content.
Organic search properties
Watch the public site that search crawlers and organic visitors must reach before content quality or ranking work can matter.
Launch and campaign sites
Track the project website during launches, migrations, redesigns, and active campaigns when an availability problem carries more immediate cost.
Multi-project portfolios
Review uptime separately for each available Screpy project so agencies and in-house teams can keep client or brand websites in one workflow.
Know the boundary of an uptime result.
Screpy supplies external HTTP evidence and incident history for the configured project website. Use infrastructure, logs, transaction testing, and search data when the question extends beyond that scope.
One project website target
Uptime Monitoring checks the public website URL configured for the Screpy project. It is not a general-purpose list of independent endpoint monitors.
External check, not infrastructure telemetry
The result describes whether the public target responded. It does not inspect CPU, memory, containers, databases, private networks, or server logs.
Incident evidence, not root-cause proof
HTTP status, timing, and incident timestamps narrow the investigation but cannot prove whether DNS, TLS, hosting, deployment, firewall, or application code caused it.
Availability is not an SEO guarantee
A working public page is necessary for visitors and crawling, but a high uptime percentage alone cannot guarantee indexing, rankings, traffic, revenue, or conversions.
Use the website-health workflow that matches the failure.
Monitor reachability over time, audit the wider website when failed URLs or crawl patterns repeat, or inspect page performance after availability is stable.
Review check-based 30-day uptime and response times, recent HTTP outcomes and recorded incidents for the project's public URL.
Crawl the wider website to find repeated failed pages, redirect problems, broken destinations, and technical patterns around an availability issue.
Run recurring lab performance checks when the website is reachable but loading or responsiveness still needs investigation.
Screpy documentation
Learn how to monitor website uptime
Learn to choose a public project target, configure monitoring and notifications, interpret response-time evidence and investigate recorded incidents.
Related SEO guides
Learn the concepts behind this workflow and apply them with practical SEO guidance.
GEO
How Does Brand Positioning Affect AI Search Visibility?
Brand positioning shapes AI search visibility by aligning category, use cases, and proof points across your site and trusted third-party sources in AI answers.
Read article GEO
What Are AI-Proof Keywords and How Do You Find Them?
AI-proof keywords are search terms that still drive visits beyond AI answers; find them with SERP checks, intent signals, tools, comparisons, and local demand.
Read article GEO
How Do You Find AI Visibility Gaps?
AI visibility gaps emerge when you compare brand mentions, citations, and competitor coverage across priority prompts, AI platforms, and topic clusters.
Read article GEO
How Do You Monitor Brand Mentions in ChatGPT?
Monitor brand mentions in ChatGPT with a repeatable prompt set, tracking citation sources, competitor share of voice, sentiment, and response trends over time.
Read articleWebsite Uptime Monitoring FAQ
Answers about sampling, inactive projects, redirects, missing checks, email eligibility and the difference between availability and page performance.
Does Screpy send downtime alerts?
Email can follow a later failure in an open incident when the response is 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 or 526. Project members and an optional distinct inbox receive qualifying notices. Outage and recovery emails each have a one-per-project-per-24-hours limit. A suppressed incident is not remailed later; recovery email requires an earlier unsuppressed outage notification. Timeouts, no-code errors and other HTTP codes do not qualify.
What does Screpy Uptime Monitoring measure?
Screpy records status, HTTP code when available, response time and timestamp for one public project URL. The dashboard uses 30-day checks for uptime and response averages, shows eight recent checks, and separately displays all-time incident counts and the latest five incidents.
How do downtime incidents and recovery work?
The first failed check opens an incident; further failures keep it open, and a later successful check resolves it. The dashboard shows status, start and details, while eligible recovery emails include recorded duration. Checks cannot pinpoint failure onset between samples or guarantee detection of every brief outage.
Does Uptime Monitoring show response-time history?
Yes. Recent response records feed the chart, with up to 160 loaded from 30 days and fewer visible on smaller screens. Its five-check trend differs from the successful-only 30-day average. HTTP response time does not measure page rendering or visitor interactions.
What does Screpy count as up or down?
HTTP 200–399 is up; other HTTP responses are down. Timeouts and request errors have separate states. Redirects are not followed, and page content is not validated: a redirect or HTTP 200 error page can be up without proving the intended page works.
How often does Screpy check website uptime?
Project settings accept 1–60 minutes and paid access is required. Within a day of project-team activity, checks use that interval. After a day they use at least 10 minutes; after seven days, at least 60 minutes. After 30 inactive days, scheduled checks stop. Always check the actual last timestamp.
Can website downtime affect crawling or indexing?
Persistent server errors can slow crawling and prevent content retrieval. An up result from Screpy is not proof of Googlebot access, successful redirect resolution, indexing or rankings. Investigate the affected URL with crawl and search evidence as well.
Does uptime monitoring replace server or transaction monitoring?
No. Screpy checks one public HTTP(S) target. It does not inspect private infrastructure, run login or checkout transactions, test page content, provide geographic availability proof or diagnose the cause of failure. Use logs and dedicated checks for those questions.
Big on SEO. Light on Your Wallet.
A comprehensive SEO toolkit at a refreshingly affordable price.
- Technical audits, rank tracking & AI visibility
- Keyword research, backlinks & uptime monitoring
- One workspace. Flexible plans. Less to spend.
More stays in your pocket