Website error monitoring from DNS to checkout

Uptimia has a monitor for each layer a website can fail on, from DNS and certificates to checkout and visitors' browsers. When one fails, the alert names the error class and the incident page keeps the response, the checkpoints that saw it and a traceroute.

Start free trial → See where a request fails
30-day free trial No credit card 171+ checkpoints

Where one page request fails

Loading a page takes five steps: DNS lookup, connect, certificate, server and page. A request can stop at any of them. Where it stops changes both what the visitor sees and how the alert is labelled.

Each alert gives the error class and the detail behind it, so you know who to call first. A resolver failure usually means the DNS provider or registrar, while a 502 points at the app behind the proxy. The incident keeps the response headers and body, the checkpoints that saw the failure, and a traceroute (the path the request took, hop by hop).

A monitor for each layer

Sign-in and checkout flows, APIs, visitors' browsers and blocklists can all break while every single page request looks fine. Each layer below has its own monitor and is shown with the alert it sends.

DNS that stops resolving

An uptime check fails as soon as a domain stops resolving, but the DNS monitor can alert before that. It queries your authoritative nameservers directly and alerts when a watched record drifts from its baseline, a nameserver stops answering, or the delegation at the registry no longer matches.

In the alertDNS records changed · A @ changed
Explore DNS monitoring →

Refused and timed-out connections

A switched-off server or a firewall rule that drops the port shows up here, and so does a route that never completes. The alert says whether the connection was refused or timed out. The traceroute on the incident shows where the packets stopped.

In the alertConnection error · Connection refused
Explore website uptime monitoring →

Expired or broken certificates

An uptime check fails on any certificate a browser would reject, such as a renewal installed without its intermediate. The SSL monitor warns earlier, inside the expiry window you choose, and alerts on a hostname mismatch, an invalid chain or a revoked certificate.

In the alertCertificate expires very soon · This SSL certificate will expire in 6 days
Explore SSL monitoring →

Error status codes and redirect loops

Out of the box, every 4xx and 5xx response fails the check, Cloudflare's 52x codes included. A redirect chain that never lands fails as a loop. The alert names the code and the incident keeps the response, so you can tell whether the proxy or the app wrote the error page.

In the alertHTTP error · HTTP Error 502 Bad Gateway
Explore website uptime monitoring →

Error text on a 200 page

Keyword rules check the text of the page the server sent. Require "Add to cart" and forbid "Fatal error", and an error template served with a 200 fails on the first check.

In the alertKeyword error · Keyword not found
Explore keyword monitoring → Explore monitoring assertions →

Broken sign-in and checkout

A real browser walks your flow step by step: sign in, search, add to cart, pay. When a step fails, you get the step number and a screenshot of the page as the customer saw it.

In the alertTransaction error · Error on step #4 · the step could not be carried out
Explore transaction monitoring →

Failing API responses

API checks chain several requests and assert on status, headers, JSON fields and response time. A write endpoint that returns 500 fails the check even while the pages and read endpoints look fine, and the alert names the failing step.

In the alertStep 2 · POST /orders — assert #1 (status is) failed — got 500
Explore API monitoring →

JavaScript errors in visitors' browsers

A snippet on your pages reports uncaught JavaScript errors from real visitors, with the message, script, line and column. It catches errors in browsers and on pages that scheduled checks never open.

In the alertToo many JavaScript errors · At least 5% of pages have JavaScript errors
Explore real user monitoring →

Malware and blocklist flags

Virus monitoring asks Google Web Risk whether your URLs are flagged for malware, social engineering or unwanted software. Blacklist monitoring watches the lists that mail providers consult before they accept your email.

In the alertMalware was detected on your website
Explore virus monitoring → Explore blacklist monitoring →
Every check runs from outside, the way a visitor arrives. Uptimia does not crawl a site for broken links and does not read server logs. You pick the URLs to watch, deep links included.

Where error evidence is kept

Errors and the evidence a check captured appear on the incident page, in the check log and in scheduled reports.

Incident page with the evidence

The error class and detail, the checkpoints that detected it, the response headers and body, keyword results, transaction steps with screenshots, and a traceroute. Export it as PDF or HTML, or share a public link.

Check log with every result

Every check with its result, location and response time. Open a failed row to read the error text the checkpoint received. Export as CSV, PDF or HTML, or share a public log link.

Incidents in reports and status pages

Scheduled reports list incidents under each monitor, with critical and non-critical counts on top. From an uptime, speed or transaction incident you can post an update to your status page.

Send each monitor's alertsto the people who can fix them.

DNS, connection, certificate, HTTP, page content, checkout, API, browser and blocklist checks, in one account.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Decide what counts as an error

Every website monitor has three settings that decide when a failed check turns into an alert. Alerts go to that monitor's contacts by email, SMS, Slack, Microsoft Teams, Telegram, PagerDuty or any other channel you connect.

Website monitor

Error types to be reported

Connection errors, timeouts, HTTP errors, redirect errors, keyword errors and SSL errors: you switch each one on or off. Under HTTP errors you also choose which response classes are rejected. Out of the box that is 4xx and 5xx.

Website monitor

Follow HTTP redirects

With it on, the check judges the page a redirect lands on, and a loop that never lands fails as a redirect error. When a URL must answer directly, switch it off and reject 3xx, so a "temporary" redirect to a holding page counts as down.

Website, API, DNS, speed, SSL and journey monitors

Outage confirmation

Set how many backup checks from other locations must also fail before anyone is paged: 1, 2 or 3. A setting of 1 alerts sooner, and 3 keeps a flaky route or a firewall rule in one country from waking you. API monitors count the primary run in the number, so 3 means the primary plus 2 other locations. At 1, API and DNS monitors alert without a re-check.

  • Contacts per monitor. Each monitor has its own contacts, so API failures can go to the backend team while blocklist flags go to whoever runs email.
  • Evidence on the incident. The alert gives the error class and its detail. The incident page adds the detecting checkpoints, headers and body, screenshots and a traceroute.
  • Recovery notice. When the check passes again, you get a message naming the monitor and how long the error lasted.
Explore downtime alerts → Explore false-positive prevention →
Recovered · shop.caldmont.com is UP after 11 minutes all-clear sent

HTTP status codes by class

The alert names whatever code the check received. Two Cloudflare codes and 408 are filed as timeouts, since the origin never answered in time. The causes listed are common ones in general web practice, so use them as a starting point when you look for the fault.

Check what a URL answers right now with the free HTTP status checker. HTTP status checker →
Locations

Errors confirmed from other locations

A single failed check can come from your own firewall, a bad route or a country block. None of those means the site is down for visitors. Uptimia re-checks a failed website check from other locations before it treats the error as real.

  • A block in one country. A bot rule or geo-block that refuses one checkpoint fails that check only. The backups from other locations pass, and nobody is paged.
  • The checkpoint list is public. Add every address on it, IPv4 and IPv6, to your firewall or bot rules so monitoring gets through.
  • Location on every log row. Each row in the check log, and in its CSV export, shows the check location, time, status and duration.
Checkpoint list → Explore multi-location monitoring →
171+ checkpoints · 70+ countries Not confirmed · nobody paged

Also included

Notes on every monitor

Add a note to the monitor: what to check first, a phone number, a runbook link. It shows on the incident page, in alert emails and in webhook payloads.

✎Restart php-fpm first · runbook/502
Incident page · alert email · webhook

Public status pages

Post an update to your public status page straight from the incident, so customers can see what is happening without contacting you.

status.example.com Investigating · checkout errors

Recovery notices

When the error clears, everyone who got the alert hears that it is over and how long it lasted.

shop.caldmont.com is DOWN10:17
shop.caldmont.com is UPUP after 11 minutes

Maintenance windows

A deploy that serves 503 for ten minutes is planned work. Schedule a window for it, and checks pause with alerts muted.

00:00Window · 02:00–03:0024:00
Alerts muted · checks paused

Scheduled reports

Incidents listed under each monitor, daily to yearly, as PDF, HTML or CSV.

Weekly · Monday 08:00
MonitorIncidents
shop.caldmont.com1 · 11 min
Checkout flow1 · 25 min
api.caldmont.com0
PDF · HTML · CSV

One dashboard for everything

Uptime, keyword, transaction, API, SSL, DNS, virus and blacklist monitors on one dashboard, with one set of contacts.

shop.caldmont.comUPTIME Checkout flowTRANSACTION api.caldmont.comAPI caldmont.comDNS caldmont.comBLACKLIST

Example failures on an online shop

Each case lists the monitor settings that catch it and what Uptimia shows while it lasts. The cases all happen on the same shop.

Example 1Uptime monitor

502 after a PHP-FPM crash

The shop starts answering 502 Bad Gateway. The nginx front end is still up. Behind it, the PHP-FPM pool has run out of workers, so nginx serves its own error page. Three backup checks from other locations get the same 502, and the incident opens with the response attached.

Monitor settings Check intervalEvery 1 minute Rejected responses4xx, 5xx Outage confirmation3 backup checks
The incident page and what happens →
On the incident page
The 502 response with its headers and body, the primary and the three backup checkpoints that confirmed it, and a traceroute. The body shows nginx wrote the error page, so the fault sits in the app behind it.
What happens
The alert reads "HTTP error" with "HTTP Error 502 Bad Gateway". Someone restarts the pool, the checks pass again, and the recovery notice says the shop was down for 11 minutes.
Example 2Uptime monitor with keyword rules

Error page served with a 200

A database password gets rotated and nobody updates the app. Every product page now prints a PHP fatal error where the products should be, with a status of 200 OK. A check that reads only the status would stay green all afternoon, but the keyword rules fail on the first check after the change.

Monitor settings KeywordMust exist · Add to cart KeywordMust not exist · Fatal error Check intervalEvery 1 minute
The incident page and what happens →
On the incident page
The keyword results and the response body the checkpoint received. The stack trace is often in the HTML as well.
What happens
The alert reads "Keyword error" with "Keyword not found". The developer fixes the credentials, the page passes again, and the incident closes with a recovery notice.
Example 3Transaction monitor

Checkout fails while every page returns 200

A front-end release renames a field on the payment form. Every page still answers 200 and loads quickly. A customer can fill the basket and reach checkout, and then nothing happens on Pay. The scheduled run stops at step 4 and keeps a screenshot of the page as the browser left it.

Monitor settings Run every10 minutes Steps4 Outage confirmation3 backup checks
The incident page and what happens →
On the incident page
Steps 1 to 3 passed with their timings, step 4 failed, and the screenshot shows the checkout page exactly as the browser left it.
What happens
Backup runs from other locations confirm the failure. The alert reads "Transaction error" with "Error on step #4" and the cause, and the screenshot shows the front-end developer which form broke.
Example 4DNS monitor and uptime monitor

Apex record pointed at a retired server

Someone tidying the zone at the DNS provider pastes an old server's address into the apex A record. That server was switched off last week. The DNS monitor asks the authoritative nameservers on its next sweep and sees the change. Visitors keep reaching the site for a while, then stop as cached answers run out.

Monitor settings Watched recordsA, MX, NS DNS sweepEvery 5 minutes Uptime checkEvery 1 minute
The incident page and what happens →
On the incident page
The DNS incident shows the A record before and after the edit. The uptime incident shows the timeouts from the checkpoints that confirmed it.
What happens
The DNS alert lands 37 minutes before the uptime monitor sees the outage. That gives you time to put the right address back before cached answers run out. Once the record matches the baseline again, the DNS incident closes by itself. If you meant to make the change, accept it as the new baseline.

Set up these checkson your own site.

Uptime, keyword, transaction and DNS monitors, each with its own alert and incident page.

Start your free 30-day trial →
30 days free no credit card cancel anytime

How website error monitoring works

Website error monitoring checks each layer a site can fail on, with a separate monitor for each: DNS, the connection, the certificate, the HTTP response, the page content, user journeys, APIs, visitors' browsers and reputation lists. Failed website, SSL, speed and transaction checks are confirmed from other locations before an alert goes out (API and DNS monitors too, unless set to 1; malware and blacklist checks are single lookups), and the alert names the error class and the detail behind it, with the evidence the check captured.

01What counts as a website error?+
Anything between a visitor and a working page: a domain that stops resolving, a refused or timed-out connection, a certificate a browser rejects, error status codes like 404, 502 and 503, error text on a page that loads, broken sign-in or checkout flows, APIs returning wrong data, JavaScript failing in the browser, and a domain landing on a malware or spam blocklist. Each sits on a different layer, so no single type of check covers them all.
02Does Uptimia scan my whole site for broken links?+
No. Uptimia is not a crawler, and it does not read your server logs. You monitor the URLs that matter, deep links included, from outside, the way a visitor reaches them. Start with your revenue paths and main landing pages, where an error costs money.
03Can Uptimia detect 404 and 500 errors?+
Yes. An uptime monitor alerts on error statuses, and you decide what counts as an error for each monitor. Out of the box every 4xx and 5xx code is an error and 3xx redirects are followed; you can switch any class on or off per monitor. Each check runs from one of 171+ locations, and a failure is confirmed by backup checks from other locations before anyone is paged.
04What do 502, 503 and 504 mean in an alert?+
502 Bad Gateway: the reverse proxy got no valid answer from the app behind it, so check that the app process (PHP-FPM, Node, Gunicorn) is running and listening where the proxy expects. 503 Service Unavailable: the server is up but declines to serve, usually maintenance mode left on, overload, or a load balancer with no healthy backends. 504 Gateway Timeout: the app answered, but slower than the proxy would wait, often a slow query or a hung call to another service. The incident keeps the response headers and body, which usually show whether the proxy or the app wrote the error page.
05Does Uptimia detect Cloudflare 52x errors?+
Yes. Every 520-to-526 code is named in the alert, from "521 Web Server Is Down" to "526 Invalid SSL Certificate". Two of them, 522 and 524, go under "Timeout error" because the origin did not answer Cloudflare in time. The code itself is still in the response saved with the incident.
06My firewall blocks the checkpoints. Will I get false 403 alerts?+
A bot rule that blocks the Uptimia checkpoints produces a real 403 from the checkpoints' point of view, so yes, until you allow them. The checkpoint list is public; allow every address on it, IPv4 and IPv6. A failed website check is re-checked from other locations before an alert, so a single blocked location never pages you on its own.
07What does an error alert contain?+
The error class and its detail, such as "HTTP error" with "HTTP Error 502 Bad Gateway", "Timeout error" with "Connection timed out" or "Keyword error" with "Keyword not found", plus when it started. The incident page keeps the checkpoints that saw it, the response headers and body, and a traceroute (the path the request took, hop by hop). Transaction failures add the failing step number and the screenshot taken at that step.
08Can I see JavaScript errors my visitors hit?+
Yes. Real user monitoring collects uncaught JavaScript errors from actual visitors, with the message, script, line and column, grouped by error message and by script, with the number of affected pages. You choose the threshold that turns the log into an alert: errors on a share of page views, measured over a number of minutes.
09Does Uptimia catch DNS and certificate errors?+
Yes. An uptime check reports "Could not resolve host" or an SSL error as soon as a visitor would hit it. For example, a renewal can install the new certificate without its intermediate, and the check then fails with "unable to get local issuer certificate". The dedicated DNS and SSL monitors catch causes earlier, such as a record that changed at your authoritative nameservers, a nameserver that stopped answering, or a certificate inside its expiry window. The free DNS checker and SSL checker show what a domain answers right now. DNS checker · SSL checker · Website health check
10Do I need a separate tool for each kind of error?+
No. Every monitor on this page lives in the same Uptimia account, with shared contacts and one dashboard, and most of them appear in scheduled reports. The free plan watches 1 website at 5-minute intervals; the 30-day trial opens every monitor type, no credit card.

Monitor each layer of your site

Each layer gets its own monitor. Failed website, checkout, API and DNS checks are re-run from other locations before anyone is paged.

Start free trial →
30-day free trial DNS, pages, checkout and APIs in one account Failed website checks confirmed from other locations No credit card
Start with an uptime check and a keyword rule, then add the layers your site needs.