Push has a deliverability problem now

The number on the screen

The first provider I sat with showed a huge subscriber base. Sends went out. I could not tell if they landed. Nothing in the product explained the gap. You pay for a number. The phones might be doing something else.

I got a bit obsessed with that. Delivery truth is a boring phrase. It is also the first thing I wanted and could not get.

Email already had this fight

Email did not get a spam folder because marketers asked for one. Inbox providers built filters when volume stopped matching value. Sender reputation became a job. The vendors who could explain why mail stopped landing kept the accounts.

I am not saying 2026 is 2003 with different logos. I am saying the shape is familiar. The platform, not the sender, now decides who still gets through.

What actually shipped

Last October Chrome said it automatically removes notification permission for sites a person has not used much, when volume is high. In January it started rate-limiting the Push API for sites it calls disruptive. A few days ago Chrome Security described a layered defense: revocation, abuse-network detection, server-side throttling, one-tap unsubscribe on Android. Safari already shipped Declarative Web Push last year so a notification can show without waking a service worker.

Those are dated public pages. I am not adding a Chrome version number the pages do not use. I am not calling any of this a Chrome spam folder. That phrase is ours, for teaching. It is not a product name.

What I do with that

If you only optimize sends, you will eventually sit on the wrong side of the browser. I do not have a clever fix for that. I have a loop I wanted: who is reachable, whether this one is worth it, what you withheld. Some of that is in the product today. Some of it is still being built. I will not pretend otherwise.

If your dashboard still cannot tell a live endpoint from a polite fiction, start there. The rest of the argument is easier once the number is honest.