Enterprise Website Monitoring: What to Monitor Beyond Uptime

This page explains what an enterprise website monitoring service should actually watch beyond a simple uptime ping, covering infrastructure, platform, application and business signals, and it is written for IT managers, digital leads and agency owners who need to know whether their current arrangement would catch a failure before customers do.

Uptime is one signal out of many

Most organisations discover their monitoring is thin on the day something breaks quietly. The status page is green. The HTTP check is returning 200. Yet enquiry forms have not delivered an email in nine days, the sitemap has not regenerated since a deploy, and the search index is serving results for products that were deleted last month. Nobody was alerted, because nothing the monitoring looked at ever went down.

A basic uptime check answers one question: did a single URL return a successful status code from a single location in the last five minutes. That is worth having. It is not website monitoring, it is availability monitoring, and the difference matters to anyone whose site drives revenue or lead generation. A site can be fully available and fully broken at the same time.

The useful way to think about it is as four layers, each of which can fail without the layer above it noticing.

The four monitoring layers

Each layer is cheaper to monitor than the one below it and less informative. Infrastructure metrics are trivially available from any agent. Business outcome monitoring requires someone to understand what the site is for. That is why so few arrangements get past layer one.

Infrastructure signals that predict outages

Infrastructure monitoring is valuable mainly because it is predictive. Disks fill at a measurable rate. Memory pressure builds. Connection pools saturate under load before they refuse connections outright. Watching the trend buys hours or days of warning.

• Disk utilisation and inode count, per mount, not per server. A log partition at 100 per cent takes down MySQL while the root volume looks healthy. Inode exhaustion from millions of session files produces "no space left on device" with 40 GB free.
• Memory, swap activity and OOM kill events. The kernel killing a PHP-FPM child or a Node process is a monitorable event in dmesg and in the journal. Alert on it directly rather than inferring it later.
• Database connection pool usage against max_connections. Sitting at 80 per cent of the ceiling means the next traffic spike produces "too many connections" rather than slowness.
• Queue depth and job age. Depth alone is misleading, because a busy queue that drains is healthy. Oldest-job age is the signal that matters.
• Backup completion and restore verification. A backup job that exits non-zero is an outage waiting to be discovered at the worst possible moment.
• CPU steal on shared or burstable instances, where the hypervisor, not your code, is the cause of the slowdown.

Platform signals: cron, workers and indexes

Every CMS runs work outside the request cycle, and almost none of it is visible to an HTTP check. WordPress leans on wp-cron unless it has been moved to a system crontab. Silverstripe runs queued jobs through a daemon or a scheduled task. Drupal has its own cron plus any queue workers the build added. Headless stacks have webhook-driven rebuilds, scheduled publishing and incremental regeneration.

The right pattern is dead man's switch monitoring: instead of waiting for an error, the job reports in when it completes, and the absence of a check-in raises the alert. Scheduled publishing, nightly imports, feed syncs, sitemap generation, abandoned cart emails and index rebuilds all deserve one. Also watch search index health separately from the application, since an index can be stale, partially built or pointing at a cluster that has quietly gone red while every page still renders.

Cache state belongs here too. A site that is fast because of a full page cache behaves very differently once that cache is cold. Watching cache hit ratio alongside origin response time tells you whether the server is coping or whether the CDN is carrying it.

Application signals: errors, slow queries and dependencies

Application monitoring is where real user impact becomes measurable. Three things are worth instrumenting properly.

Error rate rather than error presence

Every production application throws some exceptions. The signal is a rate change: 5xx responses as a percentage of total requests, broken down by route. A 2 per cent error rate confined to /checkout is a commercial emergency, while the same rate spread across crawler traffic to old URLs is noise.

Database and query performance

Slow query logs, lock waits and replication lag explain most "the site feels slow" complaints. A missing index on a table that grew past a few hundred thousand rows is the most common cause we see, and it is invisible until someone looks at query time distribution rather than average page load.

Third-party dependencies

Modern sites fail at their edges. Payment gateways, CRM and marketing automation endpoints, address lookup, SSO identity providers, mapping services, review widgets and analytics tags all introduce failure modes that your own infrastructure cannot fix but must detect. Outbound call latency and error rate per integration should be a first-class metric, not something reconstructed from logs after a complaint. Tightening the set of external scripts a page is allowed to load, through a Content Security Policy, makes that surface both smaller and easier to reason about.

Business signals: the only monitoring executives care about

The most valuable alert a website can send is "no one has completed this action in longer than expected". Enquiry forms, account registrations, logins, bookings, applications and orders all have a normal hourly or daily rhythm. Monitoring for an absence against that rhythm catches the failures that every technical check misses: a mail relay that started silently rejecting, a reCAPTCHA key that expired, a form handler broken by a plugin update, a redirect loop on a landing page served only to logged-out mobile users.

Two implementation approaches work well together. Synthetic transactions drive a real browser through the critical path on a schedule, submitting a test enquiry or adding to cart in a way the business can filter out. Real user monitoring records what actual visitors experience, including Core Web Vitals and JavaScript errors by browser and device. The distinction, and when each is worth the cost, is covered in more depth in our note on synthetic checks, RUM and alerting.

Certificates, DNS and the quiet expiry outage

A large share of enterprise outages are calendar events, not technical faults. Something expired and nobody owned the renewal.

• TLS certificates on every hostname, including www, staging, APIs, mail subdomains and anything behind a load balancer. Alert at 30, 14 and 7 days. Automated renewal through ACME still fails when a validation path is blocked by a firewall rule or a redirect added six months earlier.
• Domain registration, especially .com.au renewals tied to an ABN or a staff member who has left.
• DNS record drift, nameserver changes and DNSSEC validity, so an unannounced change by another vendor is detected rather than discovered.
• Email authentication: SPF, DKIM and DMARC records, which break transactional mail without breaking the website at all.
• API keys, OAuth client secrets and service account credentials with expiry dates.
• Platform and language end of life, where a PHP or Node version falls out of security support and the clock on unpatched vulnerabilities starts. Tracking published advisories against your installed versions is the job of CVE scanning and vulnerability monitoring.

Monitoring scope by provider type

The last column is the one that decides outcomes. Everything to its left can be bought as a product. The gap between a hosting provider that keeps a server running and a development team that can change the application is where most organisations actually get stuck, a problem we unpack in web hosting versus managed hosting.

Alert routing, escalation and alert fatigue

Unactioned alerts are worse than no alerts, because they create the belief that something is being watched. A monitoring stack that emails a shared inbox during business hours is a reporting tool, not a response capability.

Workable alerting has a few properties. Every alert has a named owner and a documented first action. Severity is tiered, so a full outage pages a human immediately while a certificate at 30 days creates a ticket. Alerts route to a rotation with automatic escalation if the first responder does not acknowledge inside a defined window. Thresholds are tuned until false positives are rare, because an engineer who has learned to ignore a channel will ignore the one alert that mattered. Flapping checks are suppressed, and every incident ends with a written record of cause, fix and prevention.

That record is the part organisations undervalue until they need it, whether for an insurer, an auditor, a board paper or a procurement review. The difference between detection and resolution is a staffing question, not a tooling one, and it is the substance of a real website support SLA.

Frequently Asked Questions

What should an enterprise website monitoring service include beyond uptime?

It should cover infrastructure metrics such as disk, memory, connection pools and queue depth, platform jobs including cron, background workers and search indexes, application signals such as 5xx rate, slow queries and third-party API failures, and business outcomes such as form submissions, logins and orders. It should also track certificate, domain, DNS and credential expiry dates. Critically, it should include an on-call team with a defined response time, because detection without response only changes when you find out.

Is 24/7 website monitoring worth it if our business operates in business hours?

Usually yes, because the failure window is not the same as the trading window. Scheduled jobs, backups, imports and automated deployments run overnight, which is exactly when a disk fills or a worker dies, and an issue detected at 2am and fixed by 4am never becomes a business-hours outage. Organisations with a real overnight audience, international visitors or transactional email flows have an even stronger case.

Does managed hosting include monitoring, or is it a separate service?

It depends entirely on the provider, and this is worth asking in writing. Many hosting plans monitor the server and the network but explicitly exclude the application running on it, so a failed cron job or a broken form is your problem. Managed hosting that includes application and platform monitoring, with a named response commitment, is a different service level to infrastructure monitoring alone.

How is availability monitoring different from performance monitoring?

Availability monitoring answers whether the site responds at all, usually by requesting a URL from several locations and checking the status code. Performance monitoring measures how well it responds: time to first byte, Core Web Vitals, database query time and error rates under real traffic. A site can score perfectly on availability while delivering an experience slow enough to lose conversions, which is why both are needed.

How many monitoring tools does an enterprise website actually need?

Most sites are well covered by three categories: an external synthetic and availability checker, an infrastructure and log agent on the servers, and an application error and performance tool. The number of tools matters far less than whether every alert has an owner, a severity and an escalation path. Adding a fourth dashboard that nobody reads reduces reliability rather than improving it.

What is a dead man's switch alert and why does it matter for CMS sites?

A dead man's switch alert fires when an expected check-in does not arrive, rather than when an error is reported. It matters for CMS sites because scheduled tasks, queue workers and import jobs usually fail by stopping entirely, which produces no error and no HTTP response to observe. Without it, a job that died weeks ago looks identical to a job that has nothing to do.

Where UnDigital fits

UnDigital runs monitoring as part of a managed service rather than as a dashboard subscription. That means the same team that receives the alert has root on the server, commit access to the application and the Silverstripe, WordPress, Drupal, Magento and headless experience to fix the cause rather than restart the symptom. Infrastructure, platform, application and business-level checks are configured per site, alerts route to an on-call rotation under an agreed response time, and every incident, patch, renewal and change is recorded in a dated log you can hand to an auditor.

If you are not certain what your current arrangement would catch, the practical starting point is an audit of the existing infrastructure and monitoring coverage: what is watched, what is not, who is paged, and how long resolution actually takes. See managed hosting for enterprise websites for how that engagement is structured, or break/fix and emergency website support if something is failing right now.