Newsletter Outage

N3onc0m3t

We mail about 300 people for an IT client and never saw anything. Read this one, the mail scanners fetch every link at once and the site falls over. https://developer.woocommerce.com/2026/07/31/our-newsletter-took-the-site-down/

Did a small shop mailing ever do that to one of yours?

Cheers

anita.rath

Yes Black Friday mail to 2k people, the host's CPU limit kicked in...

Andrew

Right, that's the mail filters: Outlook and the corporate gateways open every link before the reader sees the mail so 2k inboxes means 2k bots on the site inside a minute.

But the tracking parameters do the damage. Anything with utm_ on it misses the page cache so every one of those hits runs PHP.

N3onc0m3t

I checked our Mailchimp links just now. They all have utm_source and utm_campaign on them. And WP Rocket runs on that site.

Is that enough to skip the cache on every click or does Rocket ignore utm_ by itself?

Andrew

On most host caches any query string is a miss. WP Rocket does ignore the utm_ ones by default, so those links stay cached at that layer.

But the server cache is a separate thing and I don't know Krystal's panel. Worth asking them if utm_ sits in the cache key...

DYLAN

Best click rate that list ever had.

vijaY.jOSePh

I send a newsletter from my shop every month. About 400 people on the list as well. I've never noticed anything after a send; the site did not go down, nobody complained. But I woul not know where to look either! I open the dashboard and see visitors go up a bit. That is all.

Thanks Andrew, the Outlook part explains a lot. My list has a few business addresses on it, most are gmail. So maybe at 400 people it's just too small to matter. Is there anything in Hostinger's panel that shows those bots, or is that a log thing I can't read?

quietraven

On Hostinger this sits in hPanel. Under the website there's an analytics page and I think the access log next to it as well. That's the place to look not WordPress dashboard.

Pick the day of the send and look at first five minutes. A list of 400 people gives a slow trickle over the day. The bot burst looks different: a few hundred requests in two minutes all from data centre addresses with Microsoft or Proofpoint in the hostname and each one asking for a different link.

If that burst isn't there the list is just too small to matter.

Maryam-Razi

Did the host suspend you too? That happened with a restaurant client's mailing in spring, account off for an hour.

JavierCastro

Batches. The mail tool here sends the campaign in parts over one hour, so the scanners from each batch arrive a few hundred at a time and the server never sees the full wave, and the demo shop runs on a small VPS and it hasn't gone down once since that change. MailPoet has the same thing in the sending settings, how many mails per every five or fifteen minutes, https://wordpress.org/plugins/mailpoet/ and most hosted tools call it throttling. Zero cost! Which tool is sending the 300 mails on that client site?

N3onc0m3t

Mailchimp! Batches is the easy fix, next send gets it.

Cheers

vijaY.jOSePh

It happened to me after all. Tuesday I sent the August notes to my 400 people. Ten minutes later the shop was showing a plain error page. It came back by itself after half an hour.

I opened a chat with Hostinger support and told them about this thread. He checked the log. Lots of requests from Microsoft addresses in the first minutes, exactly like quietraven said. He turned on a setting on thier side so the utm links are served from the cache... His words not mine.

Yesterday I sent a small test mail to the same list. Nothing happened: nobody noticed anything. So that option did it for me.

Andrew

Seen that one setting fix three shops.

MatthiasKrieger

Would a CDN in front not have saved it? Since two years I have Cloudflare on the shop and the host says it catches all this.

Thanks.

quietraven

Only if that CDN also caches the HTML. On the free plan Cloudflare caches images css and js so the newsletter links still hit the server... For HTML you need a cache everything rule plus a bypass when the woocommerce_items_in_cart cookie is set. Cloudflare describes this on thier WordPress guide.

But cart and checkout never get cached anyway. WooCommerce sets DONOTCACHEPAGE on this pages since version 2 something and every cache respects it. A newsletter link to a product page is fine. A link straight to the cart with a coupon isn't and the burst lands on PHP again.

anita.rath

/var/log/nginx/access.log on the toys shop after that Black Friday mail: 1,900 hits in four minutes and the user agents were all over the place.

That's why the blocking part in the Woo post is the weak bit. Blocking scanners by user agent is just whack-a-mole.

Proofpoint, Mimecast, the Microsoft ones. They change the string every few months. The deny list is out of date the week after it's written.

Caching is the only fix that lasts. Page cache ignoring utm_ in the key or even just a fastcgi_cache with a 60 second ttl. Then 1,900 hits is 1,900 cache hits and PHP never wakes up.

Blocking also drops real readers behind a corporate proxy! Those are the people who buy.

quietraven

Fair point on user agents. i still keep a rate limit on host for wp-login and cart.

jessewells1443

Bookmarking this before the september mail goes out