Website uptime monitoring does not have to require a paid subscription. You can test whether a site is reachable by combining simple command-line checks, scheduled scripts, external automation services, and server-side logs. The important distinction is that a one-time test only shows that a website responded at one moment, while monitoring records repeated checks and alerts you when failures persist.
This guide explains how to test website uptime without paid monitoring, how to reduce false alarms, and where free methods fall short. The approach works for sites on shared hosting, VPS hosting, cloud platforms, managed WordPress hosting, or a self-managed server.
What website uptime means
Website uptime is the period during which visitors can successfully reach and use a website. A basic uptime check sends a request to a URL and records whether the server responds. A stronger check also confirms that the response has the expected HTTP status, content, and response time.
For example, a server may return a successful HTTP response while WordPress displays a database error, a maintenance page, or an incomplete application response. Therefore, a useful test should examine more than whether a network connection was opened.
Uptime monitoring usually measures four related conditions:
- Reachability: Can a monitoring system connect to the domain and server?
- HTTP result: Does the page return an expected status such as 200 OK?
- Content validity: Does the response contain a known phrase, title, or application marker?
- Performance: Does the request finish within a reasonable time?
These checks are not the same as a full performance benchmark. A site can be available but slow, or fast for the homepage while its checkout, login, database, or API is failing.
Before testing: define a useful monitoring target
Choose the URLs and failure conditions before writing a script. Start with the homepage, then consider a health-check endpoint, contact form confirmation page, WordPress login page, or another public page that represents an important function. Avoid monitoring a page that changes constantly unless the check validates a stable part of the response.
A sensible check should record:
- The UTC timestamp of each request
- The URL tested
- Whether DNS resolution succeeded
- The HTTP status code
- The response time
- Whether expected text was present
- The error message when a check failed
Use a reasonable interval. Checking every few minutes may be appropriate for a business-critical service, while a less frequently updated personal site may need only periodic checks. Excessive requests can burden a small shared hosting account and may violate a provider’s acceptable-use rules.
Method 1: Test uptime manually with curl
The quickest free method is the curl command, available on most Linux and macOS systems and installable on Windows. A header request can show whether the web server responds:
curl -I -L --max-time 20 https://example.com/The -I option requests headers, -L follows redirects, and --max-time prevents the command from waiting indefinitely. Look for the final HTTP status after redirects. A 2xx response usually indicates success, while 4xx and 5xx responses require investigation. A redirect is not automatically an outage, but an unexpected redirect loop is a failure.
To measure timing and receive a compact result, use:
curl -sS -o /dev/null -w 'status=%{http_code} time=%{time_total}\n' --max-time 20 https://example.com/For a basic content check, download the page and search for a stable phrase:
curl -fsSL --max-time 20 https://example.com/ | grep -q 'Expected page text'A zero exit code means the request and text search succeeded. This method is useful for troubleshooting DNS, TLS, redirects, and server errors, but it is not monitoring by itself. A terminal command run once cannot detect an outage that occurs later.
Method 2: Schedule a free shell script with cron
If you have access to a Linux VPS, a home server, or another always-on machine, cron can run an uptime check on a schedule. Create a script such as check-site.sh:
#!/usr/bin/env bash
URL='https://example.com/'
LOG='/var/log/site-uptime.log'
RESULT=$(curl -sS -o /tmp/site-body -w '%{http_code} %{time_total}' --max-time 20 "$URL" 2>&1)
STATUS=$?
DATE=$(date -u '+%Y-%m-%dT%H:%M:%SZ')
if [ "$STATUS" -eq 0 ] && echo "$RESULT" | grep -q '^200 '; then
echo "$DATE UP $RESULT" >> "$LOG"
else
echo "$DATE DOWN curl_status=$STATUS result=$RESULT" >> "$LOG"
fiMake it executable and test it manually:
chmod 700 check-site.sh
./check-site.shThen edit the crontab:
crontab -eAn example schedule is:
*/10 * * * * /home/user/check-site.shThis runs every ten minutes, but the exact frequency should match your site’s importance and the host’s rules. Keep logs from growing without limit by using log rotation or by writing a small, dated file. If the script runs on the same VPS as the website, it may fail to notice a wider network problem because both the monitor and site can lose connectivity together.
Improving a cron check
Require a known phrase in the response, test both HTTP and HTTPS, and alert only after two or more consecutive failures. You can send an email through the server’s configured mail system, or write failures to a separate log that another system reviews. Do not place email passwords, API tokens, or database credentials directly in a script with broad permissions.
Method 3: Use Google Apps Script for an external check
Google Apps Script can run a scheduled function that requests a URL from outside your hosting environment. The official Google Apps Script documentation for UrlFetchApp describes how scripts make HTTP and HTTPS requests. Apps Script quotas and scheduling limits can change, so check the current Google documentation before relying on it for an important site.
A simple script can record a timestamp, status code, and response time in a Google Sheet:
function checkWebsite() {
var url = 'https://example.com/';
var start = new Date().getTime();
var response;
var status = 'ERROR';
var code = '';
try {
response = UrlFetchApp.fetch(url, {
muteHttpExceptions: true,
followRedirects: true
});
code = response.getResponseCode();
status = code >= 200 && code < 400 ? 'UP' : 'DOWN';
} catch (error) {
code = String(error);
}
var elapsed = new Date().getTime() - start;
SpreadsheetApp.getActiveSheet().appendRow([
new Date(), status, code, elapsed
]);
}Create a time-driven trigger in the Apps Script interface to run the function periodically. This gives you an external observation point, although the result may not represent every visitor’s location. Google may also apply execution quotas, and a script that runs successfully is not a substitute for a multi-region monitoring system.
Method 4: Run an open-source monitor such as Uptime Kuma
Uptime Kuma is an open-source monitoring application that can be self-hosted. Its documentation and source repository describe monitors for HTTP, HTTPS, TCP, ping, DNS, and other services, along with notification integrations. You can install it on a VPS, a home server, or another machine that is independent of the site being checked.
This option provides a dashboard and alert history without a recurring monitoring subscription, but it is not cost-free in every situation. A VPS may have a hosting charge, and the monitor itself needs updates, storage, access controls, and backups. If you install it on the same server as the website, a complete server outage can take down both the site and the monitoring dashboard.
For a reliable arrangement, place the monitor on a separate provider or network, restrict dashboard access, enable HTTPS, use a strong administrator password, and keep the application updated. A self-hosted tool is part of your server security responsibility, not a way to avoid it.
Method 5: Use free automation or CI services carefully
Scheduled workflows in platforms such as GitHub Actions can run a small curl-based test from outside your hosting account. GitHub’s official Actions documentation explains scheduled workflows and their limitations. Schedules may be delayed, disabled for repository inactivity, or subject to usage and policy changes. Treat this approach as a convenient supplement rather than a guaranteed monitoring service.
A workflow can request the URL, fail when the response is not successful, and store a log or open an issue after repeated failures. Do not create a workflow that opens a new issue on every failed request. Add a retry policy and require consecutive failures before notifying someone.
How to reduce false uptime alarms
Free monitoring is useful only when its results are interpreted correctly. A single failed request may be caused by temporary packet loss, DNS changes, a rate limit, or a problem at the monitoring location. Use these safeguards:
- Retry once or twice: Wait briefly and repeat the request before declaring an outage.
- Require consecutive failures: Alert after several failed checks rather than one isolated error.
- Check from more than one network: A home connection, VPS, and external automation service provide different viewpoints.
- Separate DNS from HTTP: A DNS failure has a different remedy from an application error.
- Check the certificate: An expired SSL or TLS certificate can make a site unavailable to visitors even when the server is running.
- Record status classes: Treat 5xx responses, connection timeouts, certificate failures, and unexpected content as separate events.
Review your host’s access and error logs as well. Shared hosting control panels commonly expose recent errors, while VPS users can inspect web server, system, database, and firewall logs. Logs from the origin server cannot prove that every visitor could connect, but they help distinguish an application failure from a network or DNS problem.
Uptime checks for WordPress and other applications
For WordPress, monitor a public page that loads the theme, database, and critical plugins, not only a static image. You can also create a lightweight health endpoint that confirms the application is functioning without exposing private configuration or database details.
Do not include server paths, environment variables, database errors, debug output, or administrative information in a public health response. Disable WordPress debugging output on production sites, keep plugins and themes updated, and review security logs when checks show repeated failures. Caching through a CDN can make the homepage appear healthy while the origin, login process, or uncached pages remain unavailable, so test more than one URL when those functions matter.
Limitations of free uptime testing
Free methods have important limits. A check from one location cannot show how the site performs globally. A check of the homepage cannot confirm that payments, forms, APIs, email delivery, or user authentication work. Scheduled scripts may stop because of quota limits, machine failure, expired credentials, clock problems, or a disabled repository.
Uptime percentages also depend on the measurement interval and definition of failure. A site that fails briefly between checks may be missed. Conversely, an aggressive timeout can label a slow but functioning page as down. Keep the raw timestamps and request details so that you can explain how the result was produced.
These methods do not replace a service-level agreement, incident response plan, backups, or capacity testing. If downtime has serious operational consequences, compare paid monitoring services by checking their probe locations, alert channels, retention, status-page tools, HTTP assertions, and support terms rather than choosing solely on price.
Pros and cons of monitoring without a paid service
Advantages
- Low direct cost and flexible implementation
- Control over scripts, logs, URLs, and alert rules
- Useful learning for DNS, HTTP, TLS, Linux, and hosting administration
- Easy integration with existing cron jobs, spreadsheets, or development workflows
Disadvantages
- You must maintain the monitor and troubleshoot its failures
- Free tools may have quotas, delayed schedules, or limited geographic coverage
- Self-hosted monitors can fail at the same time as the website
- Alert delivery, log retention, and security become your responsibility
Concise Q&A
Can I test uptime with only a browser?
Yes, for a one-time check, but a browser refresh is not continuous monitoring and may use cached content. Use a scripted request for repeatable results.
Is a 200 status code proof that the site works?
No. It shows that the requested resource returned a successful status. Validate stable content and test important application functions separately.
Should I use ping to measure website uptime?
Ping tests network-level reachability, but many hosts block ICMP while serving HTTP normally. Use HTTP or HTTPS checks for a website, with ping as an additional diagnostic.
What is the best free approach?
For a small site, an external scheduled script combined with server logs is a practical starting point. For greater control, a self-hosted tool such as Uptime Kuma can add dashboards and notifications, provided it runs independently and is maintained securely.
Recommended starting plan
Begin with a manual curl test to confirm DNS, redirects, TLS, status codes, and response time. Next, schedule a check from a machine outside the web server and record results with UTC timestamps. Add content validation, retries, and a consecutive-failure rule. Then compare those observations with web server, WordPress, database, and DNS logs when an alert occurs.
This approach will not provide the geographic coverage or managed alerting of a specialized service, but it can reveal many common hosting problems without a paid monitoring plan. Revisit the setup after domain changes, hosting migrations, CDN or SSL changes, and major WordPress updates. Informational note: free-service quotas, provider policies, and hosting terms can change, so verify current documentation and avoid sending excessive automated requests.