Website monitoring is a system of automated checks that detects failures and problems before users notice them: site unavailability, slow responses, an expiring SSL certificate, form errors, failed payments. Without monitoring you learn about an outage from a customer's phone call — with monitoring the vendor learns about it, and the client receives the information in a report. This guide shows what is genuinely worth monitoring, which tools handle it and what it costs.
Key takeaway: Website monitoring covers at minimum: availability (uptime) from external locations, server response time, SSL certificate and domain validity, PHP errors and the behaviour of key functions (forms, payments). Tools cost from 0 to around 100 PLN net/month per site — and the lack of monitoring costs as much as an unnoticed outage lasts. Alerts must reach the responsible person with an escalation procedure; an email saying "something is down" is not monitoring.
What is website monitoring?
Website monitoring is a set of automated tests run in a loop: every minute, every five minutes or every hour the system checks from the outside whether the site responds correctly. When a test detects a problem, it triggers an alert — email, SMS, Slack notification.
A key feature of good monitoring: it looks from the outside, the way a user does. It does not check "whether the server is alive" from the inside, but "whether a customer from another city sees the site and can submit a form". That distinction matters — the server can be running while the site is still unavailable to users because of an application error, an expired certificate or a WAF block.
Monitoring has three layers, which are worth implementing together.
- Availability — whether the site responds at all, and how fast.
- Functions — whether key paths work: the form sends, the cart calculates, the payment page opens.
- Security and infrastructure — SSL certificate, domain, file changes, login attempts.
What is worth monitoring?
Not everything is equally easy to monitor. Priorities depend on the site type, but the common denominator looks like this.
| What to monitor | How | Why | Priority |
|---|---|---|---|
| Availability (uptime) | HTTP check every 1–5 min from several locations | Detect an outage in minutes, not days | Critical |
| Response time | TTFB and full load time measurement | Catch performance degradation | High |
| SSL certificate | Validity date and chain check | Avoid browser warnings | Critical |
| Domain | Renewal date monitoring | Avoid domain expiry | Critical |
| Forms | Test submission and delivery verification | Silent errors blocking enquiries | High |
| Payments | Test transaction or webhook | Sales stopped = real loss | Critical (store) |
| PHP errors | Error log analysis | Catch problems before an outage | High |
| File changes | Integrity monitoring | Detect infections and backdoors | High |
| Google positions | Keyword tracking | Detect drops after changes | Medium |
- Practical advice: start with the first three rows. Availability, SSL and the domain are the foundation — their absence is the most common cause of "unnoticed" outages. Form and payment monitoring follows for a site that earns money.
Availability monitoring (uptime) — how it works
Uptime monitoring sends an HTTP request to the site at regular intervals and checks the response: status code, time, content. If the response does not arrive or is incorrect, the system retries from another location (to rule out a temporary network problem), and then sends an alert.
When choosing a tool, it is worth looking at four parameters.
- Test frequency — 1 minute for revenue-generating sites, 5 minutes for others; rarer tests mean a longer detection time.
- Number of locations — tests from at least 2–3 regions; network failures between regions are everyday occurrences.
- Content verification — not just a 200 code, but also the presence of key text; a site with an empty database can respond "200 OK" and still be broken.
- History and reports — availability data over time; useful in discussions with the host.
Good uptime monitoring also has false-alarm configuration: if the site has planned maintenance or tests, they can be excluded from alerts so the team does not stop reacting to notifications.
SSL and domain monitoring
An expired SSL certificate is the most embarrassing site outage — browsers show a full-screen "Your connection is not private" warning, and users flee. And all it took was watching a date.
- SSL certificate — monitoring checks the validity date and sends an alert 14–30 days in advance; with Let's Encrypt certificates (valid for 90 days) renewal is automatic, but automation can break — monitoring catches that.
- Domain — alerts 30, 14 and 7 days before registration expiry. Domain expiry is an outage that cannot be fixed "on the spot" — the domain can enter a grace period, and the site and email stop working.
- DNS — checking whether records point to the correct server; an accidental DNS change can "lose" a site for hours.
If you manage several sites, this element is often the cause of the silliest outages — and the easiest to eliminate.
Application and form monitoring
The most costly failures are silent: the site works, looks fine, but the contact form does not send messages or the store payment returns an error. The user does not write an email about it — they simply go to a competitor.
- Forms — a test that submits a form with a unique marker and verifies the message reached the inbox; this detects SMTP, spam-filter and plugin problems.
- Payments — monitoring the payment provider's webhooks and placing test orders on a cycle (e.g. once a day) for stores.
- PHP and application errors — log analysis and error tracking tools; alert on a new error type, not on every occurrence.
- Performance — alert when response time exceeds a threshold (e.g. over 3 s for 5 minutes) — a slow site is often a precursor to an outage.
This area distinguishes "checker" monitoring from real technical care. A site can have 99.9% uptime and simultaneously not accept enquiries — because nobody checks functions.
Security monitoring
Security monitoring watches what happens to files and accounts.
- File integrity — comparing files against a baseline; new and changed files outside updates are a sign of infection (WordPress malware removal).
- Login attempts — alert on an unusual number of attempts; protection against brute-force attacks.
- Account changes — a new administrator account, a permission change, a login from a new location.
- Google blacklist — whether the domain has landed on a warning list (which happens after infections); for stores also Merchant Center monitoring.
Security monitoring does not replace hardening and updates — it is a safety net that catches what slipped past the protections.
Monitoring tools and prices
The monitoring tool market is broad — from free to extensive platforms.
| Tool | Type | Price (net) | For whom |
|---|---|---|---|
| UptimeRobot | Uptime, SSL | 0–30 PLN/month | Start, simple sites |
| HetrixTools | Uptime, blacklists, servers | 0–40 PLN/month | Sites and servers |
| Better Uptime / Better Stack | Uptime + on-call + status page | 0–100 PLN/month | Teams with on-call |
| Pingdom | Uptime, synthetic tests | from ~50 PLN/month | Companies, demanding transaction tests |
| New Relic / Sentry | APM, error tracking | from 0 PLN (free tiers) | Applications, stores |
| WP plugins (e.g. WP Umbrella, ManageWP) | Management + monitoring | 10–60 PLN/site/month | Agencies, multiple sites |
For a single company site, the set "UptimeRobot + SSL monitoring + form test" closes the topic for a few dozen PLN per month. A store needs a transactional layer — order tests and payment webhooks. Within website care, monitoring is usually included in the package rather than invoiced separately — check that when comparing offers.
Alerts, escalation and reporting
Monitoring without a procedure is useless. An alert that lands in an inbox checked once a week is no different from no alert.
-
Alert channel — email + SMS for critical failures; push notifications for less urgent ones. SMS at 3 am for every minor anomaly quickly ends with notifications muted.
-
Escalation — if nobody reacts within X minutes, the alert goes to a second person; for a revenue-generating site it is worth having that path.
-
Status page — an optional status page for clients; during infrastructure outages it saves dozens of "is it down for you too" emails.
-
Report — a monthly summary: availability, response times, incidents, actions taken. It is proof that monitoring works.
-
Practical rule: every alert should have an owner and an expected reaction. An alert without an owner is noise.
Monitoring within website care
In website care, monitoring is a standard package element — together with updates and backups it forms the safety triangle. The difference between "a plugin that sends an email" and monitoring within care is that behind the alert stands a person with a procedure and an SLA: they know what to check, in what order and how to bring the site back up.
In a well-designed care package, monitoring covers the following set.
- Availability from external locations and alerts to the vendor.
- Monitoring of SSL, domain and correct form behaviour.
- PHP error analysis and alerts about anomalies.
- Security monitoring: file integrity, login attempts, blacklists.
- A monthly report with results.
If the site earns money, a basic care package without function monitoring is a step in the wrong direction — saving a few dozen PLN per month can cost weeks of an unnoticed problem. The full picture of care with monitoring and an SLA: WordPress website care.
Frequently asked questions
How much does website monitoring cost?
Availability monitoring with alerts in free tools costs 0 PLN, and extended packages (uptime, SSL, blacklists, on-call) cost 20–100 PLN net per month per site. Within website care, monitoring is usually included in the subscription. Store transaction monitoring (order tests, payment webhooks) is priced separately.
How often should availability monitoring run?
Revenue-generating sites (stores, lead-generating services): test every 1 minute. Company sites: every 5 minutes. Rarer tests (every hour) make sense only for low-risk sites — with 60-minute intervals, an outage detected "along the way" can last for hours before anyone reacts.
Does monitoring replace backups?
No — they are complementary mechanisms. Monitoring detects a problem (and allows a quick reaction), backups allow the site to be restored after an outage or infection. The ideal setup: monitoring detects within a minute, backups allow restoration within hours. Both elements, together with updates, form the basis of technical care.
What does website security monitoring cover?
Security monitoring covers: file integrity (detecting unauthorised changes), login attempts to the panel, account and permission changes, presence on Google blacklists and in Merchant Center. It does not replace hardening and updates, but it catches the effects of vulnerabilities faster than a manual review.
Does monitoring work for a WooCommerce store?
Yes, but it needs a transactional layer: test orders on a cycle, payment webhook monitoring, checking cart and checkout behaviour. Plain uptime will not detect that the store "works" but does not accept orders.
Who should receive monitoring alerts?
The technical person responsible for the site — the care vendor or the internal IT team. Sending alerts to the business owner's inbox without technical backup ends with notifications being ignored. In care packages the alert goes to the vendor, and the client receives information about the outage and repair in the report.
Sources and tools
- web.dev — Core Web Vitals
- Google Search Central — site maintenance
- WordPress — hardening and security
- OWASP — web application security
- WordPress News — security
👉 Want someone watching your site 24/7? See WordPress development & care — monitoring of availability, SSL, forms and security with alerts to the vendor. Write via the contact form or to kontakt@informatix.com.pl.
📖 See also: WordPress website care, WordPress updates and WordPress site audit.