How Do I Get Alerted When My Website's Traffic Suddenly Drops?

You get alerted to a traffic drop by comparing recent visit counts against a rolling baseline for the same time window, and firing a notification the moment traffic falls outside the normal range for that hour or day. This is different from an uptime check, which only tells you the server answered a request — it says nothing about whether real visitors are actually arriving. A traffic-drop alert catches the failures that leave your server perfectly healthy while nobody can reach it: a broken deploy behind a CDN, a DNS record pointed at the wrong IP, an expired ad campaign, or a tracking script silently failing.

This gap is easy to miss because it doesn't look like an outage from the inside. Your health check returns 200. Your database is fine. Your error logs are empty. But traffic quietly falls to a fraction of normal and nothing in a standard monitoring setup notices, because uptime monitors are built to answer one question — \"did the server respond?\" — and a traffic drop can happen while the answer to that question is a clean yes the entire time.

What Counts as a Traffic Drop, Exactly?

A traffic drop is a meaningful fall in visits, requests, or a comparable count relative to what's normal for that specific time slot — not relative to yesterday's total, and not relative to an arbitrary fixed number. Traffic on most sites has a shape: weekday afternoons differ from Sunday mornings, and a launch week differs from a quiet one. An alert that only knows \"fewer than 500 visits today\" will either stay silent through a real drop on a normally-quiet day, or fire constantly on a normally-quiet one. That's the whole argument for a baseline instead of a flat number.

Baseline Comparison vs. a Fixed Threshold

A rolling baseline looks at the same day-of-week and hour-of-day over the last few weeks and asks whether the current count falls meaningfully below that historical range. A fixed threshold just checks a single number against a constant you set once and probably never revisit. Baselines take more setup but survive seasonality; fixed thresholds are faster to configure and are fine for sites with genuinely flat, predictable traffic, or as a first alert while you accumulate enough history to build a real baseline.

Why an Uptime Check Alone Misses This

An uptime monitor pings a URL on an interval and confirms the response code and response time look healthy. That's the right tool for \"is the server up,\" and it will catch a crashed process or a full disk immediately. It will not catch:

• A DNS change that routes some or all visitors to the wrong place while the origin server stays perfectly reachable.
• A CDN or reverse-proxy misconfiguration that serves a cached error page with a 200 status.
• A broken analytics or tracking snippet that makes traffic look like it dropped when it didn't — a real failure mode worth ruling out first.
• An expired or paused ad campaign, a lapsed backlink, or a search ranking change that quietly starves the site of visitors with the infrastructure fully healthy.

Each of those needs a check that looks at actual visit volume, not server response codes. That's a different signal from uptime, and it needs its own alert.

How to Set Up a Traffic-Drop Alert

The mechanics are the same shape regardless of where your visit counts live — server logs, an analytics platform's API, or your own request counter. On a schedule (a cron job is enough for most sites), pull the current window's count, compare it against the baseline for that window, and send an alert only when the drop crosses your threshold. Here's a minimal version using a plain cron job and the Pingwire REST API, so the alert itself doesn't depend on anything already working correctly on your site — it just needs outbound HTTP:

#!/usr/bin/env bash
# traffic-check.sh -- run hourly via cron
set -euo pipefail

CURRENT=$(get_visit_count_for_last_hour)   # your existing log/analytics query
BASELINE=$(get_avg_visits_same_hour_last_4_weeks)
THRESHOLD=0.5   # alert if current is less than 50% of baseline

if awk -v c="$CURRENT" -v b="$BASELINE" -v t="$THRESHOLD" 'BEGIN{exit !(c < b*t)}'; then
  curl -sS -X POST https://pingwire.dev/api/v1/messages \
    -H "Authorization: Bearer $PINGWIRE_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\\"channel\\":\\"ops-alerts\\",\\"text\\":\\"Traffic drop: $CURRENT visits vs $BASELINE baseline this hour\\"}"
fi

The two functions at the top are the only site-specific part — they can query your web server logs, a database table you already log requests into, or an analytics provider's API. Everything after that is generic: compare, and send if the comparison fails. If you'd rather not manage a cron job at all, the same check can run from a scheduled CI job or from inside whatever process already aggregates your logs, as long as it can make one outbound HTTP call when it decides to alert.

Picking a Threshold That Won't Cry Wolf

Start looser than feels necessary — a 50% drop, not a 20% drop — and tighten it only after you've watched it run quietly through a few normal weeks. A threshold that fires on ordinary variance trains you to ignore it, which defeats the entire purpose. It's the same principle behind dead man's switches for cron jobs: an alert only earns trust once it has gone quiet through enough uneventful runs that you believe a ping from it means something real.

What Should the Alert Actually Say?

Include the current count, the baseline it's being compared to, and the window it covers — enough to tell, from the notification alone, whether this needs an immediate look or can wait until you're at a keyboard. \"Traffic is down\" with no numbers forces whoever reads it to go dig up the same data the script already had. A body like \"142 visits vs 480 baseline, 2–3pm window\" tells the reader the severity before they click anything.

Traffic Alerts vs. Uptime Monitors: Which Do You Need?

Signal	What it answers	Catches
Uptime monitor	Did the server respond, and how fast?	Crashes, full disks, expired certs, DNS pointed at a dead host
Traffic alert	Are real visitors actually arriving, compared to normal?	Silent DNS misroutes, CDN misconfig serving cached errors, dead marketing channels, broken tracking

These two answer different questions and neither substitutes for the other. A site can pass every uptime check while a traffic alert is the only thing that would have caught the problem, and vice versa — a server can go down for thirty seconds during a low-traffic window without denting the visit count enough to trip a baseline alert. Most sites want both: uptime monitoring for \"is it up\", and a traffic check for \"is anyone getting there.\"

What About Heartbeat Monitoring for the Check Itself?

Once the traffic check is the thing standing between you and knowing about a silent failure, it's worth protecting the check job itself the same way you'd protect any other cron job: a heartbeat monitor that expects a ping every time the script runs, and alerts you if that ping stops arriving. Otherwise a broken traffic-check script fails exactly like a healthy quiet period — no alert, no error, nothing to notice until someone happens to look.

Wiring the send side up takes about the same amount of time as the bash script above. Create a free Pingwire account, generate an API key, and point your existing traffic-check job at it — or start from a REST API and webhook reference if you're building the check from scratch.