Website downtime can come from your hosting server, DNS, SSL, domain settings, a local connection, or a temporary problem affecting only one visitor. This uptime checklist shows how to monitor a website, confirm whether an alert is genuine, troubleshoot the likely cause, and keep an incident log that helps you spot recurring problems before they affect visitors or business operations.
Overview
Website uptime monitoring is the practice of checking a site at regular intervals and recording whether it responds as expected. A monitoring service can send an alert when a page becomes unreachable, returns an unexpected response, or takes too long to respond. That alert is a starting point, not always proof that your entire website is down.
Before contacting your host, confirm the scope of the issue. Open the site from a different network, such as a mobile connection, and try more than one page. If only one device or network is affected, the problem may be local DNS, browser cache, Wi-Fi, or an internet connection. If the site fails from several independent connections, investigate the domain, SSL certificate, hosting account, or server.
A basic monitoring setup has three parts:
- An external check: A tool outside your hosting account visits the site on a schedule.
- A clear alert: Notifications go to an address or channel that someone actually reviews.
- An incident log: Each event records what happened, what was checked, who responded, and when service returned.
This approach works for a portfolio, landing page, small business website, WordPress installation, or site hosted through a free website builder. It is also useful when comparing hosting providers because a record of real incidents is more informative than a general uptime promise.
What to track
1. Availability from outside the site
Choose an uptime monitor that can request your public URL at a recurring interval. Start with the homepage, then add important pages such as a contact page, booking page, shop page, or a representative WordPress post. A homepage check can show that the server responds, but it may not reveal a broken form, missing database connection, or error affecting a deeper URL.
Use a sensible check interval for your needs. A personal site may only require periodic checks, while a business site that receives leads or orders may need more frequent notification. Avoid creating unnecessary checks for every page; focus on pages whose availability matters to visitors.
2. Response results and HTTP status
Record the result returned by the server. A successful response generally means the requested page was delivered. A redirect may be expected when a site moves from one URL to another, but an unexpected redirect can indicate a domain or configuration problem. Client-side errors, such as a missing page, are different from server-side errors, which can point to hosting, application, or database trouble.
Do not treat every failed check as a confirmed outage. A monitor can experience a temporary network failure, and one check may fail while the next succeeds. Set alerts to require confirmation when the monitoring tool supports that option, and verify the site from another network before making changes.
3. DNS and domain status
Track whether the domain resolves to the intended hosting destination. DNS changes can take time to appear consistently, and an incorrect A, AAAA, CNAME, or nameserver setting can make a site unavailable even when the hosting account itself is operating normally. If you recently connected a custom domain, review the launch steps in How to Launch a Free Website with a Custom Domain.
Keep the domain renewal date in your records as well. An expired domain can interrupt access independently of the web host. Use the Domain Renewal and Expiration Checklist to add renewal reminders and confirm that the registrar account remains accessible.
4. SSL and certificate behavior
Check the HTTPS version of the site, not only the HTTP version. An expired, mismatched, or incorrectly installed SSL certificate may cause browsers to warn visitors even when the server returns a page. Test the exact hostname visitors use, including the version with and without www if both are available. For broader protection tasks, see the Website Security Checklist for Beginners.
5. Visitor-facing functions
Availability is not the same as usability. A site can load while its contact form, login, payment handoff, images, or embedded tools fail. Test the functions that matter most to your goals. For example, send a controlled test through a contact form and verify delivery using the guidance in How to Set Up a Website Contact Form.
6. A simple incident log
Use a spreadsheet, document, or support system with these fields:
- Incident ID and date
- First alert time and confirmed start time, if known
- URL or function affected
- Symptoms and exact error message
- Networks, devices, and locations tested
- HTTP result, DNS result, and SSL observations
- Hosting provider ticket number and response
- Actions taken and their timestamps
- Recovery time and verification method
- Likely cause, follow-up task, and owner
Write observations before conclusions. “Homepage returned a server error from two networks” is more useful than “host was bad,” especially when you review several incidents later.
Cadence and checkpoints
Set a routine that matches the importance of the site. A practical schedule is:
- After setup or migration: Check the preferred domain, alternate hostname, HTTPS, key pages, forms, DNS records, and redirects. Repeat after making DNS or hosting changes.
- After every alert: Verify from another network, check several pages, capture the error, and open a host support ticket if the issue persists.
- Weekly: Review whether alerts are reaching the right person and whether the monitor is checking the correct URL. Perform a quick visit to important site functions.
- Monthly: Review the incident log for repeated dates, error types, slow periods, or unresolved follow-up tasks. Check domain and certificate reminders.
- Quarterly: Compare availability trends with your site’s importance, traffic, and hosting plan. Reassess whether free hosting limits, storage, bandwidth, or support access still suit the site; the Free Hosting Limits guide can help frame that review.
Keep monitoring notifications separate from promotional email when possible. Use at least one notification route that is independent of the website itself, since site-based dashboards may be inaccessible during an outage.
How to interpret changes
Use the following decision path when an alert arrives:
- Can you open the site? If yes, test from another network and inspect the monitor’s timestamp. It may be a brief or monitor-specific failure.
- Does the domain resolve? If not, investigate DNS records, nameservers, domain expiration, and recent changes before assuming the server is down.
- Does HTTPS fail while HTTP works? Check the certificate, hostname configuration, redirect rules, and SSL settings.
- Do some pages work? A single broken page may indicate a missing file, application error, database issue, or incorrect link rather than a complete hosting outage.
- Do several networks show the same failure? Capture the time, status code, screenshots, and affected URLs, then contact hosting support with specific evidence.
Look for patterns instead of reacting to one event in isolation. Repeated failures after publishing may indicate a plugin, theme, script, or deployment problem. Failures at similar times may justify reviewing resource limits, scheduled tasks, backups, or provider maintenance notices. Slow responses without complete downtime belong in the same log because declining speed can become an availability problem for visitors. Pair this review with the Website Speed and Uptime Checklist.
When contacting support, include the domain, affected URL, time zone, first and latest failure times, error message, test networks, and any recent changes. Avoid deleting files, changing DNS repeatedly, or restoring backups before you have preserved evidence and identified the likely failure area.
When to revisit
Review this uptime process after any host migration, domain connection, SSL change, WordPress update, major site redesign, or change to a contact or checkout flow. Revisit it immediately after an outage alert and after support confirms a resolution so you can verify the result independently.
On a normal schedule, review the monitor and incident log monthly. Perform a deeper hosting and DNS review quarterly, or before renewing a hosting plan. If your site is growing, compare its needs with the practical limits of the current setup rather than waiting for repeated failures. The free hosting comparison guide can support that evaluation without treating any single provider as permanently best.
Start today: add your main URL to an external monitor, test the alert notification, create the incident-log columns listed above, and record a baseline check for the homepage, HTTPS, DNS, and one important function. That small setup turns “Is my website down?” into a question you can answer with evidence.
