The site never went down. The uptime monitor stayed green all weekend. Analytics looked normal. And a few days of enquiries went somewhere nobody thought to look.

That’s the shape of most migration damage. Not the 502. A 502 gets fixed inside ten minutes because everyone sees it at once, including the client. The expensive failures are the ones with no symptom on the front end: mail that authenticates on the old IP and not the new one, a cron job that never came across, a certificate that is valid today and will fail to renew long after everyone has stopped paying attention, orders written to a database that is about to be deleted.

This post-migration checklist covers the first 48 hours after cutover. It’s ordered by when each failure actually becomes visible, not by category, because that ordering is what decides which problems you catch yourself and which ones reach you as a client ticket a fortnight later.

Why a post-migration checklist should be ordered by detection latency

Most migration checklists you’ll find are grouped by subsystem: DNS, SSL, email, SEO, performance. That’s a fine way to write a document and a bad way to work a cutover, because it treats a 500 error on the homepage and a broken certificate renewal as equally urgent. They aren’t. One will be reported to you within minutes by someone who isn’t you. The other has a detection latency measured in weeks, and it lands at 3am.

So sort your checks by how long the failure can hide. Short latency, catch it reactively. Long latency, go and look for it on purpose, while you still have the old server, the old data and a rollback path. That’s what makes 48 hours the right frame: long enough for a full daily cron cycle and for DNS to settle at any sane TTL, short enough that the old server is still sitting there with the evidence on it.

Hour 0 to 1: prove you are actually looking at the new server

Almost everyone starts by loading the site in a browser and saying it looks fine. That check is worth close to nothing an hour after cutover. Your laptop may still hold the old answer, your ISP resolver definitely might, and if you added a hosts entry during testing you’re now testing the thing you already tested. Ask several resolvers directly, then bypass DNS entirely and talk to the new IP.

# What is each public resolver answering, and how long will it keep answering it?
dig example.com A @1.1.1.1
dig example.com A @8.8.8.8
dig example.com A @9.9.9.9

# Talk to the new server directly, ignoring DNS completely
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# Which certificate is that IP presenting for that hostname?
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -issuer -dates

The full dig answer section, not +short, matters here because it shows the remaining TTL. That number tells you how much longer stale answers can survive, which is the single most useful figure you have in the first hour.

The --resolve flag pins a hostname to an address for that one request, so you get the new server’s response with the correct SNI and Host header. It’s the closest thing to a definitive answer you’ll get while records are still in flight. If you want to see what the rest of the world sees, an exit in another country helps, and a VPN account with NordVPN or Surfshark is a cheaper way to get one than spinning up a box in a second region.

Things to confirm in this window:

• The response comes from the new server, verified by something unique to it rather than by the page looking right. A temporary header or a file at a path that only exists on the new box removes all doubt. Pass test: you can name the specific artefact that proves it.
• The correct virtual host is selected, not a catch-all default. Sites with several domains on one server fail here quietly, serving the wrong document root over a valid certificate. Pass test: every hostname you migrated returns its own content, checked individually.
• The certificate chain is complete on the new box, not just the leaf. Browsers often paper over a missing intermediate using cached data; API clients and payment callbacks do not. Pass test: an external SSL checker reports a complete chain from a machine that has never visited the site.
• Redirect behaviour matches the old server exactly. HTTP to HTTPS, www to apex or the reverse, trailing slashes. Pass test: a handful of known deep URLs return the same final status and location as before.
• Any hosts file entries you added for testing are gone. Leave one in place and you’ll misread every check you run for the next two days.

Hour 1 to 6: the split-brain window, where you lose data instead of uptime

This is the part that costs real money, and it’s the part almost nobody checks, because during it both servers are healthy. Some resolvers still hand out the old address. Those visitors reach the old application, which happily accepts their form submission, their order, their uploaded file, their account signup. Then you delete that server.

“Keep the old server running for 48 hours” is standard advice and it’s necessary, but on its own it makes the problem worse rather than better. A running old server that still accepts writes is a data-loss machine. What you want is an old server that stays reachable and stops accepting writes.

Three options, in order of how much I’d trust them:

1. Proxy the old server to the new one. Every request that lands on the old address gets forwarded to the new backend, so there is only ever one database. This is the only option that genuinely eliminates the split, and it’s worth the extra config on anything transactional.
2. Redirect the old server to a hostname that only resolves to the new IP. Cheap, works for GET traffic, does nothing useful for a POST that’s already in flight.
3. Put the old application into a read-only or maintenance state. Safe, but visitors on stale DNS see a broken site for the length of your TTL, so this only works if that number is genuinely small.

Whichever you pick, go and look at what the old box actually did after the cutover.

# On the OLD server: has anything been written since cutover?
grep '"POST ' /var/log/nginx/access.log | tail -n 50

# Apache layouts vary; on DirectAdmin the per-domain log lives here
grep '"POST ' /var/log/httpd/domains/example.com.log | tail -n 50

# Is the old box still receiving mail for the domain?
tail -n 200 /var/log/maillog

Every POST in that log after the cutover timestamp is a potential lost record. Take the list to the application: compare row counts or highest IDs on the write-heavy tables between old and new, and reconcile before you decommission anything.

Mail deserves its own pass. If MX records changed, messages go to whichever server the sending system had cached, and land in two different mailboxes. Keep both able to accept mail through the overlap, and check the old mailbox before you close the account, not after.

Two more things here that won’t show up in any log you’re watching:

• Anything pinned to an IP address. Payment gateway allowlists, webhook endpoints, database firewall rules, SMTP relay authorisations, third-party API allowlists. None of these follow a redirect. A webhook posted to the old IP returns a perfectly good 200 and the new application never hears about the payment.
• Outbound connections from the new IP. Your application is now calling other people’s APIs from an address they’ve never seen. If any of those partners allowlist by IP, the failure appears as a timeout in a background job rather than an error on a page.

Hour 6 to 24: everything that runs on a schedule

Files and databases get migrated. Scheduled work frequently does not, because it lives outside the document root and outside the database dump, and because nothing on the site breaks when it’s missing.

# Every user's crontab, not just root's
for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done

# systemd timers, where a lot of "cron" actually lives now
systemctl list-timers --all

# WordPress: what is scheduled, and is anything overdue?
wp cron event list --fields=hook,next_run_relative,recurrence
wp config get DISABLE_WP_CRON

Run that on both servers and diff the output. That comparison is the whole check, and it takes two minutes.

The specific traps worth knowing:

• The old server’s cron is still running. Nobody stops it, because “keep it up for 48 hours” sounded like keep everything up. Now your nightly export runs twice, your reminder emails send twice, and your billing job runs against a database nobody is reading. Disable cron on the old box at cutover, before you disable anything else.
• WP-Cron was disabled in config and the replacement never came across. If DISABLE_WP_CRON is true and no system cron hits wp-cron.php, every scheduled task stops silently. Scheduled posts sit at “Missed schedule”, backups stop, WooCommerce action queues back up. The site itself works perfectly.
• The cron URL is wrong in a way that still returns success. A job calling an http:// URL that now redirects to HTTPS gets a 3xx, exits zero, and looks healthy in the log while the task never executes. Same story for a cron still pointing at the old hostname or an old absolute path.
• Backups. The job may have moved and still be writing to storage credentials, a mount, or a destination path that only existed on the old host. Don’t check that the backup job ran. Check that a file arrived at the destination, and that it’s the size you expect.
• Log rotation. A fresh server often has no rotation configured for application logs. Nothing goes wrong for three days, then the disk fills at 2am and every write fails at once.

Hour 24 to 48: the delayed detonations

These are the checks with the longest detection latency, which makes them the ones most worth doing deliberately.

Certificate renewal, not the certificate

A copied certificate is valid for weeks. What breaks in a migration is the machinery that replaces it: the webroot path in the renewal config no longer exists, the ACME account keys weren’t copied, port 80 is closed on the new firewall, or a WAF is now intercepting the challenge path. None of that surfaces until the renewal window opens, long after everyone has moved on.

# What does certbot think it manages, and how does it validate?
certbot certificates

# The only check that matters: will the NEXT renewal succeed?
certbot renew --dry-run

# Is anything actually going to run it?
systemctl list-timers | grep -i certbot

The dry run validates against Let’s Encrypt’s staging environment, so it exercises the real challenge path without consuming your issuance quota. Resist the urge to fix a failure with a forced renewal: Let’s Encrypt applies rate limits per registered domain and a separate limit on identical certificates, and burning through them during a migration is how a fixable config problem turns into a week of waiting.

Mail identity on an address with no history

If the new server sends mail, it’s sending from an IP that receiving systems have never seen. Authentication correctness and reputation are two separate problems and they fail differently. Authentication failures bounce or land in spam immediately. Reputation problems look like intermittent delivery to one provider and normal delivery to another.

# Reverse DNS for the new sending IP
dig +short -x 203.0.113.10

# Does SPF still authorise everything that sends for you?
dig +short TXT example.com

# DKIM selector (replace 'selector') and DMARC policy
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Send a test message to an address at a major provider and read the full headers. The Authentication-Results header tells you whether SPF, DKIM and DMARC each passed, and crucially whether the passing domain aligns with the visible From address. SPF can pass for the envelope sender and still fail DMARC when the From domain differs, which is a failure mode you cannot see from the sending side.

Leave the old server’s SPF authorisation and DKIM public key published through the overlap. Mail that was queued or delayed on the old path still needs to verify. Sources differ on how long to keep them, and the honest answer is: until you have confirmed nothing is still sending or retrying from the old host.

If transactional mail matters to the business, the migration is a reasonable moment to stop sending it from a web server at all. Handing it to a dedicated provider such as Postmark, Mailgun or Amazon SES moves reputation off an address you’ve just changed and gives you delivery logs you can actually query.

Search crawl, redirects and staging leftovers

Crawlers hit harder than usual after a move, because they’re re-checking old URLs and discovering new ones at the same time. That surge is also your best early warning: it surfaces broken redirects faster than your own testing will.

• Fetch robots.txt from the live site and read it. A staging Disallow: / that survives cutover is the single most damaging thing on this list.
• View source on several page types and check for a leftover noindex tag and for canonical tags pointing at a staging hostname.
• Watch 404s in the access log rather than in a crawler report. It’s your missed-redirects list, sorted by how much anyone cares.
• Leave the old URLs crawlable through the redirect. Blocking them means the redirects are never seen.

Resource behaviour under real traffic

Staging never told you what the process pool does at peak. Twenty-four hours of production traffic does.

# Status code distribution since cutover
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Disk, and the one people forget
df -h
df -i

Compare the ratio of 5xx to total requests against the old server’s logs for the same weekday. Absolute numbers mislead here; the ratio doesn’t. Watch memory across a full daily cycle rather than at a single moment, because the interesting shape is a slow climb into a limit, not a spike.

Before you decommission the old server

The old server is the only copy of some things, and none of them are in your backup.

• Access and error logs covering the cutover window, which is your evidence for anything that surfaces next month.
• Mail spools, and any messages that arrived after the MX change.
• The full crontab set, exported to a file rather than a screenshot.
• Web server, PHP and database configuration, so you can diff a behavioural difference you notice later.
• A final database dump taken after write traffic stopped.

Keep the TTL low until you’ve decided you’re staying. Raising it back to normal is the last step of the migration, not the first thing you do once the site loads. Another month on an InterServer or Contabo VPS is cheap next to reconstructing a week of orders, and the overlap is the only period in which rolling back is still a five-minute operation.

Troubleshooting: three symptoms and what they usually mean

“It works for me but not for them.” Almost always a resolution split. Get the affected user to report what their resolver returns, then check whether the answer is stale DNS, a corporate resolver ignoring your TTL, or a CDN edge still holding the old origin. If you use Cloudflare or a similar proxy in front, remember the origin change and the DNS change are two separate things and only one of them propagates.

“The site is fine but our mail goes to spam now.” Work in this order: reverse DNS for the sending IP, then SPF including the new address, then DKIM signing on the new host, then DMARC alignment with the visible From domain. Only after all four pass should you start thinking about reputation and volume, and reputation on a new IP is a matter of ramping gradually rather than something you can configure.

“Random 500s that never happened in staging.” Look at limits before you look at code. Process pool size, memory limits, database connection caps, open file limits, and file ownership on directories the application writes to. Permission problems after an rsync or archive restore are common and produce errors that look nothing like permission problems from the front end.

Common mistakes in the first 48 hours

• Treating a green uptime check as verification. It confirms one URL returns 200. It says nothing about mail, cron, writes or checkout.
• Leaving the old server fully operational, cron and all, instead of leaving it reachable but inert.
• Testing while a hosts file entry is still in place.
• Raising the TTL back to normal on day one, which throws away your fast rollback.
• Checking that the certificate is valid instead of checking that renewal works.
• Silencing monitoring for the maintenance window and forgetting to unsilence it.
• Declaring the migration done before a full daily cron cycle has completed on the new server.

If you only do five things

1. Stop writes and cron on the old server, but keep it reachable.
2. Run certbot renew --dry-run and confirm a timer or cron will actually invoke it.
3. Send a real test email to a major provider and read the Authentication-Results header.
4. Diff the scheduled jobs on both servers, then confirm one real backup file landed at its destination.
5. Grep the old server’s access log for POST requests after the cutover, and reconcile anything you find.

FAQ

How long should I keep the old server running after a migration?

Long enough that no resolver anywhere is still handing out the old address, plus enough margin to reconcile data and pull logs. For most sites that’s a few days. The cost of the extra billing period is trivial compared with losing your rollback path, but keep it inert: reachable, not writable, with cron disabled.

Why is my site fine but email broken after a server migration?

Because web and mail are validated by different systems using different records. The web path only needs an A record and a certificate. Mail needs the MX record, reverse DNS on the sending IP, SPF listing that IP, DKIM signing configured on the new host, and DMARC alignment with your From domain. A migration can satisfy the first set completely and break every item in the second.

What should I check first if something looks wrong right after cutover?

Establish which server you are talking to before you diagnose anything else. Use curl --resolve to pin the hostname to the new IP and compare that response with what you get through normal DNS. Half of post-cutover panic is people debugging the old server.

Can I lose form submissions or orders during DNS propagation?

Yes, and it’s the most common serious loss in a migration. Visitors on cached DNS reach the old application, which writes to the old database. Nothing errors. Proxying the old server to the new backend removes the problem entirely; short of that, freeze writes during the overlap and check the old access log for POST requests before decommissioning.

Why did my SSL certificate stop renewing weeks after the migration?

The certificate itself migrated fine; the renewal configuration didn’t. Common causes are a webroot path that no longer exists, an ACME account directory that wasn’t copied, port 80 blocked by the new firewall, a proxy or WAF intercepting the challenge path, or no timer scheduled to run the renewal at all. A dry run within 48 hours catches all of these.

Do I need to tell search engines about a server migration?

If the URLs are unchanged and only the hosting moved, no announcement is required. Your job is to make sure crawlers can reach the new server, that nothing carries a staging noindex or a blocking robots rule, and that canonical tags point at live URLs. If the domain or URL structure changed, that’s a different migration with its own redirect and site-move process.

What monitoring should I add specifically for the 48-hour window?

Add checks for the things a homepage ping cannot see: a synthetic transaction through a real form or checkout, a heartbeat from each scheduled job, certificate expiry, and a content check that asserts the right text is present rather than just a 200 status. Most uptime platforms handle the first and last; heartbeat monitoring for cron is the one people skip and the one that catches the silent failures.

The one thing worth remembering

A migration doesn’t fail when the site goes down. It fails when the site stays up and something behind it stops, quietly, in a way nobody is looking for. Every item on this post-migration checklist exists because the failure it catches produces no visible symptom on the front end.

So work the 48 hours in order of detection latency. Prove which server you’re on, close the write path on the old one, diff the scheduled jobs, dry-run the certificate renewal, and read the headers on a real test email. Then, and only then, raise the TTL and let the old box go.

Need a second pair of eyes on a cutover?

Migrations are one of the few pieces of infrastructure work where the review matters more than the execution. Things I help with:

• Planning the cutover so the write path is closed on the old server rather than left open, including proxy-forward setups for transactional sites.
• Running the 48-hour verification pass on a migration someone else performed, and telling you plainly what’s still broken.
• Repairing certificate renewal, ACME challenge paths and reload hooks that stopped working after the move.
• Fixing mail on a new IP: reverse DNS, SPF, DKIM signing and DMARC alignment, or moving transactional mail off the web server entirely.
• Rebuilding scheduled jobs, backup destinations and log rotation on the new host, with heartbeat monitoring so silence becomes an alert.
• Reconciling data written to the old server during the split window, before anything gets deleted.

If you’re mid-migration or just came out of one, send me something concrete: the old server’s access log around the cutover, your crontab, or the headers from a test email. That’s usually enough to tell you what’s wrong.

The post Post-Migration Checklist: What Breaks Quietly in the First 48 Hours appeared first on John Nessime.

Both are accurate. The probe hits the homepage every minute from a datacenter, gets a 200 back, and moves on. It never logs in, never adds anything to a cart, and never runs the third-party payment script that is throwing a JavaScript error on one browser version. The check was answering a question nobody was asking.

That gap is what the synthetic vs real user monitoring argument is actually about. It isn’t a tooling preference or a budget line. It’s about which failures each approach is structurally incapable of seeing, and what happens when you only run one of them.

This post covers what each method really measures, the blind spot in each that bites hardest, how to choose when you can only afford one, and how to wire both together so they explain each other instead of arguing.

The blind spot that bites hardest: silence is not health

Start with the one that catches people out, because it is invisible until the worst possible moment.

Real user monitoring is passive. A script in the page collects timings and errors from actual visitors and beacons them back. No visitors, no data. So when your site is genuinely, completely down, the browser never loads, the RUM script never executes, and your error rate goes to zero.

Zero errors. A flat, quiet, beautiful dashboard. During an outage.

I’ve seen teams build alert rules on RUM error counts and then wonder why nothing fired. A threshold alert on “errors above X” cannot fire on a metric that has stopped reporting. If you alert on RUM at all, you need a companion rule on the absence of data, and that rule needs a sensible window, because low-traffic sites go quiet at 3am for entirely normal reasons.

The mirror-image problem on the synthetic side is quieter but just as expensive. A scheduled probe only ever tests what you told it to test. Every path you didn’t script is unmonitored, and it looks exactly the same on the dashboard as a path you did script and that’s working. Coverage gaps and healthy systems are visually identical.

So: synthetic monitoring is blind to what you forgot to check. RUM is blind when nobody is looking. Neither of those is a small caveat.

Synthetic monitoring: what a probe actually measures

A synthetic check is an active request on a schedule, from infrastructure you don’t own, against an endpoint you do. It ranges from a plain HTTP GET up to a full scripted browser session that logs in and walks a purchase flow.

The simplest useful version is something you can run by hand right now. This asks curl to throw away the body and print only the timing breakdown, which tells you where the time went rather than just how much of it there was:

curl -o /dev/null -s -w 
  'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}n' 
  https://example.com/

Each value is cumulative from the start of the request, so you subtract to get the phase. A slow time_namelookup is DNS. A gap between time_connect and time_appconnect is the TLS handshake. A gap between time_appconnect and time_starttransfer is your application thinking. That last one is the number that actually correlates with user-visible slowness on a server-rendered page.

If you’re already running Prometheus, the self-hosted version of this is the blackbox exporter. It probes endpoints from outside and exposes the result as metrics. The config below is the whole trick: Prometheus doesn’t scrape the target, it scrapes the exporter and passes the target as a URL parameter.

scrape_configs:
  - job_name: blackbox-http
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com/
          - https://example.com/checkout
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Those three relabel rules have to run in that order: copy the target into the query parameter, keep the original URL as the instance label so your graphs are readable, then overwrite the scrape address with the exporter. Get the order wrong and Prometheus scrapes the exporter’s own metrics endpoint, you get no probe_* series at all, and everything looks fine because there’s nothing red to see.

The metrics you’ll actually alert on:

groups:
  - name: blackbox
    rules:
      - alert: EndpointDown
        expr: probe_success == 0
        for: 3m
        labels:
          severity: critical
      - alert: CertExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 21
        for: 1h
        labels:
          severity: warning

The certificate one is worth setting up even if you do nothing else. It’s the single highest-value synthetic check most small teams are missing, and it catches a failure mode that takes an entire site offline with no warning and no gradual degradation to notice first.

Where synthetic monitoring wins

• It works with zero traffic. A B2B app with forty users, a staging environment, a newly launched site: synthetic is the only thing that will tell you anything at all.
• It’s a controlled baseline. Same location, same schedule, same request. When the number moves, something on your side moved. RUM numbers shift because a marketing campaign brought in traffic on older phones.
• It tests paths users haven’t taken yet. A new region, a failover route, a payment provider you just switched to. RUM only ever sees sessions that already happened.
• It runs before deploy. The same scripted journey can gate a release in CI and then run on a schedule against production.
• It’s what an SLA is measured against. Availability commitments need a defined, repeatable observer. Real users are not that.

Where synthetic monitoring falls down

• The probe is on a better connection than your users. Datacenter fibre, a modern browser engine, no browser extensions, no battery throttling. It is a best case, permanently.
• Coverage equals imagination. Whatever you didn’t think to script is a silent gap, and it will be the thing that breaks.
• Scripted journeys rot. Every selector change, every A/B test, every consent banner redesign can break the check. Flaky synthetics that cry wolf get muted, and muted checks are worse than no checks.
• Cost scales multiplicatively. Frequency times locations times journeys. A one-minute browser check from eight regions is a very different bill from one HTTP check every five minutes.

Real user monitoring: what the browser actually reports

RUM is a small JavaScript agent that reads the browser’s own performance APIs and ships the results somewhere. Google’s web-vitals library is the reference implementation for the metrics that matter, and it’s deliberately tiny:

import { onCLS, onINP, onLCP } from 'web-vitals';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name:   metric.name,
    value:  metric.value,
    rating: metric.rating,
    id:     metric.id,
    path:   location.pathname
  }));
}

onCLS(send);
onINP(send);
onLCP(send);

Three things are worth understanding about that snippet. The callbacks fire when the metric is final, not on a timer, which is why Interaction to Next Paint can only be reported near the end of a session. sendBeacon is used instead of fetch because it survives the page being closed. And metric.rating gives you the good / needs-improvement / poor bucket without you hardcoding thresholds that Google may revise.

If you’d rather not build the collection side, the managed options split roughly into full-stack platforms (Datadog RUM, New Relic, Dynatrace), error-tracking tools that grew into RUM (Sentry), and open-source agents you can point at your own backend. Grafana Faro is the notable one in that last group: a browser SDK that ships web vitals, errors and traces to a collector you run yourself or to Grafana Cloud, which means your frontend signals land next to your Prometheus metrics and Loki logs instead of in a separate tab.

Where RUM wins

• It’s the only source of truth for Core Web Vitals. Google assesses LCP, INP and CLS from field data at the 75th percentile, via the Chrome User Experience Report. A perfect Lighthouse score is a lab result and carries no weight in that assessment.
• It surfaces the long tail. Mid-range Android on a congested mobile network is a cohort no synthetic probe represents, and it’s frequently the cohort that fails.
• It segments the way the business thinks. By country, by ISP, by device class, by page template, by traffic source. That’s how you find out the paid social landing page is the slow one.
• It catches client-side-only failures. A third-party tag that starts blocking render, a JS exception on one browser version, a consent script that stalls. The HTML came back 200. The page is still broken.

Where RUM falls down

• No traffic, no signal — the silence problem above, plus useless percentiles on any low-volume page.
• It’s reactive by construction. Every data point is a user who already had the bad experience. RUM cannot warn you about anything.
• You are sampled, ad-blocked and consent-gated. A meaningful slice of visitors never report, and they’re not a random slice. Privacy-conscious, extension-heavy users skew toward desktop and toward certain regions.
• The agent costs what it measures. You’re adding JavaScript to a page in order to find out how much JavaScript is slowing it down. Keep the agent small and load it late.
• Field data lags. CrUX aggregates over a trailing window, so a fix you shipped this week won’t show up in the assessment for weeks. Ship it, then wait, and resist re-litigating.

Synthetic vs real user monitoring: the honest split

Strip away the vendor framing and the division is clean. Synthetic answers “is the thing I defined still working?” RUM answers “what are people actually experiencing right now?”

Which means they belong to different jobs. Synthetic owns availability, contractual uptime, certificate and DNS health, and regression gates in CI. RUM owns experience, Core Web Vitals, conversion-adjacent performance work, and prioritisation. If you find yourself arguing about which is “better”, you’re comparing a smoke detector to a customer satisfaction survey.

Synthetic tells you something broke. RUM tells you whether it mattered, and to whom.

How I’d decide what to run first

Most teams can’t stand up both properly in the same quarter. Here’s the order I’d work in.

1. Get an external uptime check up today. Any of them. UptimeRobot, Better Stack, Pingdom, or blackbox exporter if you already run Prometheus. It must live outside your own infrastructure, or it dies with the thing it’s watching. Do check the current terms on free tiers before you build a client’s alerting on one, since several now restrict commercial use.
2. Add TLS expiry and DNS resolution checks. Cheap, and they catch total outages that have no warning phase.
3. Decide whether you have traffic. If a typical page gets meaningful daily sessions, RUM will produce usable percentiles and should come next. If it doesn’t, skip RUM entirely for now and spend the effort on scripted journeys instead.
4. Script your two or three money paths. Login, search, checkout. Not twelve. Each one is code you now have to maintain. Checkly is built around exactly this if you want the checks living in your repo as Playwright specs; Grafana Cloud Synthetic Monitoring covers the same ground with k6 scripts if your dashboards already live in Grafana.
5. Add probe locations only where you have users. Frequency times locations is your bill. Two well-chosen regions beat eight decorative ones.
6. Layer RUM last, and start read-only. Look at it for a month before you attach a single alert to it. You need to know what normal looks like per page template.

One thing worth checking before you buy anything: what your hosting already gives you. Managed WordPress plans and VPS providers like InterServer often include basic availability alerting and a status page, and Cloudflare exposes edge-side request and error data for anything behind it. That may be enough of the availability layer that you can spend the budget on the experience layer instead.

Mistakes that look like monitoring

• Running the check from inside the network it monitors. If your probe and your app share a VPC, a datacenter, or a DNS resolver, a shared failure takes out both and you learn nothing.
• Probing a health endpoint that always returns 200. A route that returns a hardcoded OK without touching the database is testing your web server’s ability to serve a string. Make the check exercise a real dependency, or add a content assertion on a page that only renders correctly when the database answers.
• Alerting on averages. A mean page load time hides every user who had a terrible one. Use p75 for experience work, because that’s what Google assesses, and p95 or p99 when you’re hunting outliers.
• Alerting on a single failed probe. One-off network blips are constant. Require consecutive failures, or failures from more than one location, before you wake anyone.
• Treating a Lighthouse score as a monitoring signal. It’s a diagnostic on a simulated device. Useful for finding the cause, worthless as an assessment of what users get.
• Letting synthetic traffic pollute analytics. Scripted browser checks look like sessions. Filter them out by user agent or a header, or your conversion rate quietly develops a dent.
• No alert on missing data. Applies to both sides. A probe that stopped running and a RUM stream that stopped reporting both look like calm.

Making the two views agree

The payoff for running both isn’t two dashboards. It’s that each one narrows the search when the other fires.

• Use consistent labels across both. Same page-template names, same region names, same environment tags. Otherwise correlating them is manual archaeology every time.
• Define availability from synthetic, experience from RUM, and write it down. avg_over_time(probe_success[30d]) is your uptime figure. p75 INP is your experience figure. Don’t let the two SLOs drift into using each other’s data.
• Let RUM tell you what to script next. When RUM shows a page template failing for one device class, that’s a synthetic check waiting to be written, throttled to match.
• Let synthetic explain RUM regressions. RUM says LCP got worse on Tuesday. Synthetic’s stored waterfall from Tuesday tells you which resource started arriving late.
• Alert on synthetic, investigate with RUM. Pages should come from the deterministic signal. The noisy, high-cardinality one is where you go to figure out the blast radius.
• Keep the scripted journeys in version control alongside the app they test, so a selector change and its check update land in the same pull request.

Frequently asked questions

Is uptime monitoring the same thing as synthetic monitoring?

Uptime monitoring is the simplest form of synthetic monitoring: a scheduled request checking for a successful response. Full synthetic monitoring extends that to multi-step browser journeys, API sequences, DNS, TCP and traceroute checks. Same category, different depth.

Can real user monitoring replace uptime checks?

No, and this is the most expensive misunderstanding in the whole synthetic vs real user monitoring discussion. RUM depends on pages loading. When the site is down, the RUM stream goes quiet rather than red, so an outage looks identical to a slow night unless you have explicitly alerted on the absence of data.

How often should synthetic checks run?

Work backwards from how fast you need to detect a problem, then account for the consecutive failures you require before alerting. A one-minute interval with a three-failure threshold means roughly three minutes to detection. Cheap HTTP checks can run frequently; browser journeys usually run every five to fifteen minutes because they cost far more per execution.

Does RUM slow down the site it’s measuring?

Slightly, and it’s a real trade-off rather than a rounding error. A minimal web vitals collector adds very little; a full session-replay agent is a much heavier thing to load. Load the agent asynchronously, sample sessions rather than capturing every one, and measure the agent’s own cost before you decide it’s free.

Why does my synthetic check pass while PageSpeed Insights fails?

They’re measuring different things from different places. A synthetic HTTP probe checks that a response came back; PageSpeed Insights reports both a throttled lab simulation and field data from real Chrome users. Neither is wrong. If the field section fails, real users on slower devices are having a worse time than your probe is.

Do I need both if I run a small brochure site?

Usually not. A low-traffic site gets almost nothing out of RUM because there aren’t enough sessions to make a percentile meaningful. Run solid external uptime and certificate checks, look at Search Console’s Core Web Vitals report for whatever field data exists, and add RUM when traffic justifies it.

Can I self-host all of this?

Yes. Blackbox exporter plus Prometheus and Alertmanager covers synthetic; Grafana Faro with a collector you run covers RUM. The catch is that self-hosted probes lose the one property that makes external monitoring valuable, which is independence. Run at least one check from a network you don’t control, even if everything else is yours.

The one thing worth remembering

Synthetic vs real user monitoring isn’t a choice between two products that do the same job. It’s a choice about which blind spot you’re willing to live with, and the answer to that changes as your traffic changes.

If you take one thing away: a quiet dashboard is not evidence of health. Synthetic monitoring goes quiet when you never wrote the check. RUM goes quiet when the site is down. Both silences look exactly like everything being fine, and both need an explicit alert on missing data before you can trust the green.

Need help getting your monitoring to match reality?

This is a good chunk of what I do. If your uptime page says one thing and your users say another, I can help with:

• Setting up external synthetic checks with sensible thresholds, so alerts fire on real failures and stop firing on network noise
• Blackbox exporter, Prometheus and Alertmanager configuration, including TLS expiry and DNS resolution alerting
• Scripting the two or three user journeys that actually earn money, and keeping them in version control next to the app
• Adding real user monitoring with Grafana Faro or a hosted RUM platform, sized so the agent doesn’t become the performance problem
• Building Grafana dashboards that put availability and Core Web Vitals side by side with consistent labels, so you can correlate them during an incident
• Auditing existing monitoring for coverage gaps, missing-data alerts, and checks that pass for the wrong reasons

Send me a screenshot of your current alert rules, a scrape config, or just the endpoint that keeps going green while people complain, and I’ll tell you what it’s missing.

The post Synthetic vs Real User Monitoring: What Your Green Dashboard Isn’t Telling You appeared first on John Nessime.