
A green uptime badge answers only one question: did a monitoring service receive a response? A website can return a successful status while loading slowly, showing a certificate warning, losing enquiries or failing at checkout. Useful monitoring follows the parts of the site that matter, then alerts someone who can act.
An uptime check requests a URL at regular intervals and records whether it receives the expected response. Monitor the home page, but also include a representative page that depends on WordPress, its database and any important integration. A lightweight server health URL may stay available while the customer-facing site is broken.
Check from outside the hosting environment. Where the audience is mainly Australian, include an Australian test location and use a second region when practical. Record status codes and confirm expected page text so that a generic error page is not mistaken for success.
Availability does not reveal whether pages have become painfully slow. Record response time and look for a sustained change from the site's normal range rather than reacting to one isolated result. Test at consistent intervals and locations because network distance affects measurements.
Be clear about the metric. Google's guide to Time to First Byte explains that TTFB includes redirects, DNS lookup, connection setup, TLS negotiation and the wait for the first response byte. It is not the time required to render a complete page, so pair it with an occasional browser-based performance test.
Automated certificate renewal is valuable, but automation can fail after a DNS, permissions or configuration change. Monitor the certificate presented on every public hostname, including the www and non-www versions, and alert well before expiry. Check the hostname, expiry date and certificate chain, not merely whether port 443 answers.
Certificate monitoring should remain independent of the renewal process. The Let's Encrypt integration guide recommends tracking renewal failures, retrying gracefully and sending errors to the responsible administrator.
DNS directs visitors to the services behind a domain. Monitor that the expected nameservers remain authoritative and that important A, AAAA, CNAME and MX records return the intended values. Cloudflare's DNS documentation describes authoritative nameservers as the servers holding the definitive records for a domain.
Keep an approved record of critical DNS values so an alert can show what changed, not just that something differs.
A site is not healthy if visitors can browse but cannot complete the next step. Test the few journeys that directly support the business:
These are synthetic transactions: automated steps that imitate a visitor's journey. SolarWinds' documentation gives examples such as mailing-list registration and shopping-cart flows. Use test data, exclude test leads from reporting and avoid actions that charge cards, consume limited stock or send repeated customer messages.
A domain expiry can affect the website, email and connected services together. Keep auto-renewal enabled where appropriate, maintain a current payment method and send reminders to more than one responsible person. Record the registrar, owner and renewal date in the business asset register.
For generic top-level domains, ICANN advises registrants to keep contact information current so renewal notices arrive. A calendar reminder outside the registrar account provides another layer of protection.
Every alert needs an owner, a backup contact and an escalation path. Send urgent outages and transaction failures to a channel that is watched during operating hours, then escalate if nobody acknowledges them. Less urgent certificate, domain and performance warnings can go to a service queue with enough lead time to investigate.
Alerts should name the failed check, affected URL, detection time, test location and latest error. Review contact details whenever staff or suppliers change.
One failed request may be a temporary network issue, a monitoring probe problem or planned maintenance. Retry before paging, and for widespread services confirm the failure from another location. Use different thresholds for a complete outage, a slow response and a non-urgent warning.
Schedule maintenance windows, pause checks during intentional migrations and test every alert route after configuration. Do not suppress repeated failures indefinitely. Group duplicates into one incident and send a recovery message so the team knows when service has returned.
Start with checks that someone will maintain. Add coverage when a new service or customer journey becomes important. Monitoring should reflect the current website.
Monitoring helps you detect problems; it does not replace suitable hosting, maintenance or backups. If your WordPress site needs a platform designed for business use, review Hosting Australia's WordPress hosting options and choose resources that match the site's workload.
The goal is not a dashboard full of green lights. It is early, trustworthy notice when customers cannot reach the site, pages slow down or an important business process stops working.



