Push Notification Gateway Pricing

Dear Rocket.Chat users,

Our open source platform has come a long way since the start of our journey in 2015. With usage numbers now in the millions, we are facing increasing operational costs. We have discussed ways to soften the load this causes on our resources, while at the same time ensuring that the service we provide remains fully available to the community at the same high standard we always strive to maintain.

Therefore, in order to mitigate some of these costs, we have decided to make a small adjustment to the way our push notification service is offered at higher volumes.

The basis for this decision was a comprehensive statistical analysis performed on our push notification dataset. We have found that the notification volume tends to follow a Pareto distribution. This means that roughly 20% of the installed base is responsible for 80% of the push notification usage. On the flip side, 80% of the base reports fewer than 1000 notifications per month.

In the next few weeks, we will start offering a dedicated push notification package for customers who use over 1000 monthly push notifications. We believe that we are offering convenience and good value in exchange for a fair price, with the ultimate goal of ensuring that Rocket.Chat remains available and operational for the community at large.

Instances using fewer than 1000 monthly push notifications will not be charged. Additionally, anyone who wishes to have full control over the push notification services can host their own servers and integrate with the Apple and Google networks without purchasing the package, as was already the case.

Thank you!

Gabriel Engel


@gabriel.engel Very well understood!
Two questions which may arise for others as well:

  • Is it 1000 notifications per consuming server (DNS name) or 1000 per user (user GUID)?
  • How to configure an own gateway? I’ve read the docs, but they write about using a custom app. What if we’re just using the stock Rocket.Chat app?


This could be a bit of a kicker for some.

There needs to be some clarification on the rate limits because that can make a huge difference.

There are probably a lot of wasted notifications. If I am at my desk and have autoaway set, but don’t have focus on the Rocket, I can get notifications to my phone because I haven’t checked the desktop app for a while, which are unnecessary. Multiply that by several users and you can get a lot of notifications that are not needed. I am not sure of the answer to this, but it is an avenue to look at.

Yes it is possible to set up your own notification service, but the bar to doing this is pretty high. You need to buy in to the Google eco system for starters. And then a iOS dev account, and presumably have to roll your own apps. The irony for that is the high volume users you are targeting probably have the time and resources to do it themselves, and when faced with the new costs may decide it is more cost effective to do so, thereby losing you the very market you are aiming at. What happens then? Reduce the limit further to try and balance the revenue/costs?

I also note that the Documentation talks about the Cordova app, which is now deprecated, and there is nothing on the React/Kotlin versions?

I fully appreciate the position that Rocket is in, but I’m not sure this will have the outcome you are after.

1 Like

Just as a follow up…

1000 notifications per month.

30 or so notifications a day between even 6 users is just 5 notifications per device per day.

So quite honestly unless notifications are off this is going to apply to the vast majority of users, not just the ‘20% of large users’.

Unless my maths is badly wrong.

1 Like

If the community can help to minimize the costs for Rocket.Chat, it would be useful to write a good manual for the operation of your own “Push Gateway” and what the procedures at Google and Apple are like. As @reetp mentioned, there are certainly many operators of larger installations who can do this. This could reduce the volume on gateway.rocket.chat considerably and Rocket.Chat could not take over any costs for third parties.

This brings me to the question of how high the costs are now?

Per workspace (or server) this will be grouped based on the registration not based on DNS to avoid any sort of duplicates counting towards.

Actually updating the doc now to hopefully make this a bit more clear: Push Notifications - Rocket.Chat Docs

But if you run your own gateway you will have to run your own apps.

It all boils down to having to compile creds into the actual app to work with GCM / APN.

Yeah this is definitely a possible scenario. One that I run into from time to time. Though with desktop application not so often as the idle detector seems to do a pretty good job of detecting when truly idle vs just not in focus.

Our aim definitely isn’t to isolate anyone. We have no plans of rushing into this and cutting off anyone’s push notification access. This will be a soft cap at first. We will be evaluating closely.

Reference has been removed for cordova in the refactor of the doc.


Will there be a documentation for pricing of push notifications?
For now I believe: 100 people are in one channel, so while there is a single message pushed, it counts for 100 push messages.

How will accounting be organised? We run four servers listening on different domains (multi tenant (teams) feature would be great), but still we are one company. Can we register four servers in one account and will have 1.000 messages for each instance?

Soft cap sounds great, is this thread the right channel -to keep an eye on- for news on this?

Great things may cost, so I’m with you.

At the moment, we are organizing them by “workspace” and each individual server that runs on a different domain (can be a little more complicated than this) will have their own limit of one thousand push notifications. This is as is, but we will let everyone know should it change.

1 Like

What about direct server - client (mobile) notification.
What are the reasons for not doing that? Even if it is an optional mode.

this … app should direct contact server if there is something new … (with changable interval)…
it will be top!

What if we would like to use more than 1000 messages/month?

There are tons of problems with this approach. Among them:

  • battery
  • background task killed
  • reliability

Shoot a message over to sales, this is currently best option. We will keep everyone updated when some other process comes out

there is no problem with this, let us decide please. If i can define in app check interval, i see no problem here.

1 Like

As always it’s super easy to say something like that. But much harder to do. ;-). We are always open to pull requests for features like this. So if you or someone else wants to take a crack at this please do!

There is always also the option to compile your own apps if you want to instead use your own creds from Google and Apple. The code for all of our apps are also open source. A few others have gone this route.

Important to reiterate though. This limit is not yet being enforced.

1 Like

Could you tell how secure push notification is?
Do you actually send text or not?

Thanks for explaining.

if this limit will be enforced i have no other option.

Probably more secure than your emails, unless you use PGP :slight_smile:

It’s a bit of an odd question with no real answer.

You could ask say ‘is a push message encrypted?’ etc.

In any event, first it will be ‘only as secure as your server’ or ‘only as secure as your phone’

Worth a search online to read about how push notification works and you can then ask clearer questions.

“if this limit will be enforced i have no other option.”

Unfortunately running a notification server is not a zero cost exercise.

Someone is paying something somewhere and subsidising your usage.

It’s not totally unreasonable for you to contribute towards costs.

So, if they decide to charge you could turn notifications off.

Or here is how to run your own:


1 Like

Is there a reason the gateway keys for private servers have to be compiled into the app? Wouldn’t it be possible to make the client pull them from the server when it first joins and then store them locally for future use?