Notifications are a pain.

Getting good, reliable notifications with Beeminder is fraught. I care about this, both because I enjoy using Beeminder and want it to work well for new users, and because I’m building TaskRatchet and the fact that Beeminder hasn’t managed to figure this out yet doesn’t bode well for me.

Channel Issues
SMS Only available in the US; may incur costs depending on phone plan. Also, it’s a premium feature, since it costs Beeminder money to send the messages.
Mobile push Phones actively fight the app’s ability to reliably push notifications on schedule (for good reasons–battery life, preventing apps from spamming, etc). Every phone handles it differently. Support spends a lot of time trying to help people get notifications fixed on their particular phone. Depending on the phone, often the user has to fiddle with settings to get it to work even half-way reliably.
Browser push / PWA Maybe it would work? Has Beeminder ever played with this option?
Email Can get caught in spam; many people minimize time spent in email; competes with everything else in inbox
Calendar ICS Calendar apps take their sweet time to pick up changes; no good way to force updates through.
Google Calendar Google has locked down their ecosystem. Either requires expensive security audits, or user has to copy-paste code and do scary things with permissions.
Automation apps Viable for Android, but I think iOS is much more locked down as to what you can do. Also takes a lot of work on the user’s end to set up custom automations–basically doing visual programming.
Custom scripts Extremely flexible, but user has to be ok with coding and/or using other people’s unofficial code. User shoulders maintenance burden. User has to figure out where to run the code in order to provide notifications in the right context.
Slack or other messaging apps Requires Beeminder to support and maintain an integration for a messaging app that most people probably don’t otherwise use.

I know people are able to find solutions that work for them (I rely heavily on Android Automate), but it irritates me that there isn’t any solution that can be recommended without caveat.

Thoughts? How could the situation be improved?


Browser push won’t be supported on iOS Safari until iOS 16 comes out, but that’s soon!

1 Like

Dang, this is a really good summary of how difficult every conceivable notification channel is! My main strategy as a user is keeping my dashboard open and in view all day long until I have everything out of the red.


My strategy is very similar: I always have my dashboard open in a tab that I visit often (I can trust myself to do this, but if I couldn’t I’d throw it up on my second screen). Then every day I “touch” everything, even if that’s just to decide I don’t need to do anything with it, and once I’ve decided, I send it to the bottom using zzq’s browser extension.

Every day’s goal is to do all of that before 7pm to satisfy my stopbyseven goal, whiiiich should actually have a deadline of 7:05pm and doesn’t yet, hm, why’s that? Done. And that one should notify me on my watch… done: reminders start at 5pm, to avoid wolf-crying at times I couldn’t possibly have done everything. And it should probably be in the red most of the time, now that I’ve confirmed that the concept actually works for me… also done.


Are you including local iOS notifications in “mobile push”? I have an app that raises a notification X seconds after you put the app in the background and I’ve never seen it be late. If you can set the time of the next notification while the app is open, it seems very reliable.

1 Like

On Android, local notifications set to arrive in the future are not
reliable at all (sob sob the stories I can tell), and Android loudly
and explicitly asks you to use (internet requiring) push notifications
instead. :frowning:


There must be some kind of exemption for alarm clock apps (one would think). Maybe we need a separate Beeminder Alarm Clock companion app and it talks to the regular Beedroid to get the alarm times. Or something? Very dumb that Google makes it this hard!

I mean, yes and no. Android has made it unbelievably complicated and heavy-handed, enough that Android was in the news a few years ago for squashing the alarm notification on the official stock alarm clock, and then vendors do their own thing…

Multiple times, they’ve made a high priority notification, and then vendors and Google itself will squash that priority for battery reasons, so they make super high priority notifications for the next revision.

For a while (maybe they’ve backed away from it a bit since Android 12, it isn’t entirely clear), they were basically telling everyone to move to push notifications to trigger background work if it needed to be scheduled finer than within a 10 minute window, and wasn’t a literal alarm clock.

It seems like they’ve realized how horrible they’ve made it, as Android 12 has 2 new permissions for exact alarms, and Android 13 goes a little further. They’ve announced a new Play Store policy around exact alarms that goes into effect in July 2023. If they do fix it by then, within 2 or 3 years, lots of users will have the changes! (For a little while, it looked like we weren’t going to be able to use them. One is literally only for alarm clock apps, timer apps, or “calendar apps that show notifications for upcoming events”. The other has wider use cases, but also some caveats I haven’t read through completely.)

There is also a new exact alarm type, kinda like what pops up when you get a phone call, and it’s possible that will work better for offline notifications. We will likely have to coalesce notifications, but that seems to be how it’s going everywhere.

For Android development, you have to remember that every API call to Android APIs has a target API version, and it runs on a device with an OS version. (Like iOS, actually, so far) This means that an API call usually runs as the version you target as the app author, even if the device is running a higher OS version, but sometimes higher OS versions will modify how API calls work even when you’re still targeting an older version. Additionally, many devices are not running a stock Android, and have their own set of tweaks and processes in the mix. They usually run the compatibility suite before releasing, but… For a good example of vendor stuff, take a look at

Despite Android team promise to enforce OEMs to be transparent about non-standard app killing, in Android 11 Samsung has introduced a new severe (default ON) restriction. Apps can no longer hold wake lock in foreground services. This breaks many use-cases, for instance health apps are now unable to gather sensoric data for their users.

After 3 days any unused app will not be able to start from background (e.g. alarms will not work anymore). Imagine, you won’t use your alarm clock for the weekend plus 1 day and bang! no alarms anymore and you miss work!

This means a user that has widgets and notifications but doesn’t open the app (not uncommon) will stop getting notifications after a few days, with no way to tell that’s happened. On some phones. Sometimes.

Another quality one is

Every day is a new opportunity to ride a horse down the beach, think about things, and yell “We finally really did it. You maniacs! You blew it up!”


The IFTTT Beeminder->Google Calendar integration works really well in my experience. I made a separate calendar for Beeminder, and IFTTT adds any beemergencies to it as a calendar event. Users can set default notifications if they want, but personally I manually go through each event (beemergency) every day and add my own notifications, because some of my goals need notifications many hours in advance whereas others are good with 5-30 minutes.

It also helps with visualizing your deadlines, if you’re the type to spread your deadlines throughout the day.


Most of my goals are time-based, so I’ve often wondered how hard it would be to set the time with the deadlines and kind of space them out.

1 Like