How much traffic we send your site

The number, and where to find it

Open any HTTP monitor and look for Traffic we send. It reads something like:

≈ 5 760 requests/day
4 regions × every 60 s

That is what your monitor costs the site it watches, per day, from all of HowlOps.

Why regions multiply it

A monitor assigned four probing regions is checked from four places, independently. Each of those places sends its own request every interval. Four regions at a sixty-second interval is four requests a minute, not one:

requests per day = regions × 86 400 ÷ interval in seconds

The multiplication is the point of multi-region monitoring. One vantage point cannot tell "the site is down" apart from "our route to it is broken", so several check independently and compare notes. It does mean the traffic scales with the number of regions, and until now nothing in the product said so out loud.

If several of your monitors watch the same hostname, the box shows that total too — that is usually where a surprising figure comes from.

It is an upper bound

The number is computed from your configuration, not from checks that already ran, so it is the most we would ever send. Two things can make the real figure smaller and nothing can make it larger:

• Politeness backoff. When a site refuses us — a 429, a Retry-After, a bot-protection block page — we check it less often until it stops. A site that asks us to slow down gets its wish without you having to do anything.
• Our own rate ceiling. We cap how many requests any single hostname receives from HowlOps across every customer. If a popular target is watched by many accounts at once, the intervals stretch rather than the site being hammered.

A paused monitor sends nothing, and says so.

If it is more than you want

Turn any one of the three dials:

1. Lengthen the interval. Going from 30 s to 60 s halves the traffic. For most sites the difference in how fast you learn about an outage is a matter of seconds.
2. Use fewer regions. Two independent vantage points are enough to tell a real outage apart from a local network problem. Four are for when you genuinely care where an outage is visible from.
3. Point the monitor at a purpose-built health endpoint rather than a heavy page. A small /health route costs the site far less per request than a homepage that renders a database-backed template.

If you are monitoring somebody else's site and they have asked you to ease off, this box is the number to quote them, and the interval is the dial to turn.

Related

• Probing regions — what each region is for
• How we treat robots.txt — why a check is not a crawl
• Our prober — the addresses we check from, and how to allow them through a firewall