OneSignal's free plan gets a 1,000 MAU cap. What it actually changes.

If you run a mobile app on OneSignal's free plan, you have had an email, or you are about to. This post is what the change is, who it actually touches, and — if you decide to move — what a migration really costs, including the part that does not work.

We build Notibase, which is an alternative to OneSignal, so read the last section knowing that. The first three sections are the same whoever you end up with.

What changed

OneSignal's own billing documentation now states that "on the Free plan, you must have fewer than 1,000 monthly active users (MAU) to send mobile push and in-app messages". It applies to new customers from 1 September 2026 and to existing customers from 1 October 2026.

That is their documentation, and it is the only thing worth trusting on the subject — plans change and blog posts do not notice. Read it yourself: documentation.onesignal.com/docs/en/billing-faq. (Checked 28 August 2026.)

Who this actually hits

Narrower than the panic suggests, and worth working out before you do anything.

Unaffected:

• Anyone under 1,000 monthly active users. Most side projects, most new apps.
• Web push. The cap is on mobile push and in-app messaging.
• Email and SMS, which keep whatever limits they already had.
• Anyone already on a paid plan.

Affected: free-plan apps with more than 1,000 monthly active users that send mobile push or in-app messages. If that is you, mobile push stops working rather than degrading — worth knowing, because a notification channel that silently stops is the kind of failure you find out about from a customer.

Two dates, not one. New accounts hit it on 1 September; if you already have an account, you have until 1 October. That is five weeks to decide rather than five days, which is enough time to do this properly instead of at 2am.

Why a MAU cap feels different from a send cap

This is the part worth understanding regardless of what you decide, because it is the thing that will or will not happen to you again.

A cap on monthly active users prices the size of your audience. You pay for having people, whether or not you message them. An app with 5,000 monthly users that sends one notification a month is over the line; an app with 900 that sends one an hour is not.

A cap on messages sent prices what you do with the audience. The same two apps land the other way round — and that is the way round that matches the cost of running the thing, because delivering 900 notifications an hour is work and having 5,000 people in a database is not.

Neither is wrong, exactly. But a MAU cap means your bill moves when your app grows even if your usage does not, and that is a surprise waiting for the quarter you have a good month. It is worth checking which shape any provider you consider uses, including ours.

Your options, honestly

Stay and pay. If OneSignal does what you need — journeys, templates, A/B testing, a visual workflow builder — this is a real answer and possibly the right one. Switching providers to save a subscription is a bad trade if you then rebuild features for three weeks.

Cut your MAU. Rarely possible, occasionally is: if a big share of your "active users" are dormant accounts you never message, some apps can get under the line. Check the definition in their docs before betting on this.

Move. Which is worth doing with your eyes open, because one part of it does not work anywhere.

What a migration actually costs

The honest version, which applies to any provider you move to:

Your mobile subscribers travel. FCM tokens were issued by your Firebase project and APNs tokens are bound to your Apple team and bundle id. Neither belongs to your provider. Point a new provider at the same credentials and the same devices receive the same notifications. Nobody re-opts-in and nobody notices.

Your web push subscribers do not. A browser subscription is cryptographically bound to the VAPID key pair that created it. Without that exact private key, every send to those subscribers fails with a 403 — forever, silently, with no way around it. OneSignal does not export the private half, and neither do most providers.

This is a property of the web push standard, not a product decision, and anyone who tells you they can migrate web subscribers without that key is describing subscriptions that will quietly never arrive. Plan for your web audience to re-subscribe, or run both providers on web for a while.

Your campaign history does not travel either. Export what your reporting needs before you close anything.

If you are looking at Notibase

We meter messages sent, not monthly active users. Subscribers are unlimited on every plan including the free one, which is 10,000 sends a month — where 10,000 people is 10,000 sends, not one campaign. Push, email, SMS, in-app messages and an in-app inbox are one audience and one API. Current numbers are on the pricing page, read live from the same source the product bills against.

A OneSignal CSV export imports directly — we detect the format and map the columns, then show you exactly what would happen, row by row, before anything is written.

Things we do not have, so you find out now rather than in week two: message templates, A/B testing, a visual journey builder, a preference centre, RCS, and multi-language sends. If any of those is load-bearing for you, stay where you are. That is not modesty, it is the shortest path to you not wasting a week.

The full mapping — every OneSignal API field and SDK call against its equivalent — is in the migration guide.

Sources: OneSignal billing FAQ, read 28 August 2026. If you are reading this much later, check it again — we will not always be the first to notice a change.