Reducing Beeminder Burnout: Not-tracking every event aka "Gentle Nudge"? Feedback Welcome!

Disclaimer: This is experimental. I’m going to try this out. I understand it’s definitely not for every goal or every person.

I tend to add so many goals it’s difficult to keep up, and sometimes I just crash and burn on beeminder. So I have this idea: not track every event. For some goals, especially “every day” goals, this could be an alternative, useful way to engage with Beeminder.

I’m tracking brush teeth every day, and that’s good and fine. So I need to start scooping my litter every day as well. The litter is right there next to my sink. One typical beeminder solution is to add scooplitter as an everyday event, requiring me to update progress every day (including auto-ratchet to beemergency every day). But I might not want to have the beeminder pressure of an every day beemergency along with the administrative work of incrementing every time I scoop.

So I’m considering making “scooplitter” every 5th day, auto-ratchet 5 days. But I’ll still attempt to scoop litter every day; it’s right there next to my sink. I will only be required in beeminder to do it once every 5th day, and I will only track that 5th day event. I will also scoop litter on my off-days, but I will neither track nor increment beeminder on my off-days.

In this manner, beeminder acts more like a gentle nudge. I only need to pay attention to that goal in beeminder when it becomes a beemergency. It’s more like a reminder, “hey you want to do this every day, remember?”.

(Another variation on this would be to require performance 6/7 days. But then still scoop the litter on the 7th day and not track it in beeminder. Then eventually go to 5/7 days and not track the off days.)

I think this alternate method of tracking progress may be worthy of consideration. This provides a different perspective on what the goal means, which in a way is more freedom to me, while still maintaining scooplitter as a true goal in beeminder. I think the pro might be less burnout and it would better exercise other systems for staying on task outside of beeminder. The cons, of course, is that I’m not tracking every event, and potentially susceptible to lower productivity.


If your “do it every day but don’t log every day” scheme doesn’t yield the results you want, or for anybody else reading this who gets fed up with logging but likes having a million goals, I’ve found using NFC stickers smooths a lot of the friction of logging.

I stuck them all over my house, and now when I do something, I just scan it with my phone and it logs to beeminder. This drastically reduced the overhead of logging data, while still actually logging.


Just to note, NFC stickers are a general solution to reducing friction. It’s not necessarily an either-or proposition: one could use NFC stickers to reduce friction along with the not-track-every-event idea. The benefit of the latter is still some reduction in beeminder stress.

But I will admit, this not-track-every-event idea is very niche. And experiemental for me at this point.


I like this idea! It’s a sort of “sampling” approach to the goal: I sample every 5 days, and if I’m still on track then, it’s been going on ok in the meantime.

Better still, if we view it as sampling, would be to sample randomly every, say 1-N days, with the interval being selected at random each time. Hard to do without some coding to set up the road ahead, but it’s an interesting enough idea I might have a go at writing that!


The idea that pops into my head here is some kind of system that auto-adds data points for you on random days that adhere to the slope of the road, but occasionally asks you to confirm that you really did do the thing (and maybe yesterday, or in the last x days where x makes sense with the slope of the line) so you’ll derail if you haven’t actually been doing what you said you would.

And then the next step would be that the proportion of “must confirm” days would go up and down depending on the confirmation rate.

Which kind of feels like second-order beeminder.

Actually that’s kind of like tagtime on a longer time scale?


Great, I’m glad you like it! I’d like to drill down on an issue I’ve considered with this type of goal.

You might find that there there is a question of what to do on the non-beeminder days, if one should desire to increment. There is a strong case against doing so. That is, one should never try to get ahead by recording on an off day.

If one allows it, you get presented with a weasely option on beemergency day: “well I did it yesterday, so I could back-date count that and not do it today”. It is sort of technically true and allowable, but I think it’s weasely to justify not-doing this kind of task that has become a beemergency today.

A good way to think of this is, “beeminder knows nothing about the off days”.

With my regular periodic implementation, this goal is essentially equivalent to something that MUST be done every Friday, for example. The fact that I want to accomplish this on every other day of the week as well, that’s entirely up to me and entirely outside of beeminder.

With a randomized implementation, this goal is essentially equivalent to an event that MUST be done on days that are triggered by a nonpredictable event. The fact that you want to also accomplish it on other days is entirely outside of beeminder.

Anyways, I wanted to share that. I think that’s a clean way of looking at it.

1 Like

I absolutely love brainstorming, thank you for sharing. That said, I think that deviates from the spirit of what I’m suggesting and may introduce some philosophical issues.

The idea that pops into my head here is some kind of system that auto-adds data points for you on random days that adhere to the slope of the road, but occasionally asks you to confirm that you really did do the thing

I think this risks having fake data entered into the system. Fake Data Is The Devil | Beeminder Blog

or in the last x days where x makes sense with the slope of the line so you’ll derail if you haven’t actually been doing what you said you would.

This sort of adds back in the beeminder pressure that (assuming you want to do this thing every day) every day is an actual beemergency. Again, I’m not criticizing your idea here, but it’s not in alignment with the original idea, which is to reduce beeminder pressure and allow the exercise of other systems to support your continued successes. Other systems could be things like the fact that it’s become habit or accountability partner or a simple reminder on your daily to-do list.

Also, you might have some penalties for not accomplishing the task on off-days, but those penalties would not be beeminder penalties. That’s also part of the stress reduction.

Which kind of feels like second-order beeminder.

The way I think of it, I want beeminder to cleanly remain as a first order system. The event must only be beeminder tracked on days in which it is a beemergency, and “beeminder knows nothing about off-days”. Off days are 100% outside of beeminder. That creates a very clean division which I think also respects beeminder philosophy.


@clivemeister I keep going back and forth on this, whether this non-increment on off days is really a big deal or not. I think this additional requirement overcomplicates one’s interaction with Beeminder.

The spirit is that the goal’s purpose is to act as an occasional reminder that you want to do this thing every day, but without the every day beeminder pressure.

So a solution would be to set a very low slope, and auto-ratchet to 5 days, and recording any progress is OPTIONAL (with a general bias that you don’t). Then it really doesn’t matter if you increment on a non-beemergency day. You’re always constrained by an approx 5 day window. And if you back-date a goal in order to get out of doing it TODAY, well, that’s actually fine according to the goal settings. It’s sort of weaselly, but still legitimate.

The fine print would specify that data entry is optional and a clause whether or not one is allowed to enter data for a prior day.

1 Like