Test the new autodialer

I’ve identified two problems:

  1. Like you intuited, it wasn’t built to handle goals with anything other than date+rate end segments. Since people explicitly opt into the autodialer, I think it’s fine if I coerce the last segment to be date+rate on dial, as long as I include that as a known limitation.
  2. The dialer function has been timing out, which is a good problem to have, though I’m a bit stumped as to how to solve it. Netlify functions time out at 10 seconds. I’ve been trying to get the main function to spawn child functions, one per user, but I’ve been having trouble with that, too, since the main function needs to wait until the ssl handshake completes before exiting, but the only way I know to do that is to wait for the child to respond… so not sure how to approach this.
1 Like

Very cool idea!

What’s the intended functionality for goals that are less than 30 days old? Will it wait with the first autodial until the goal is 30 days old, or use the average of the shorter period, or …?

1 Like

One thing I foresee being a potential pitfall (but maybe it’s already accounted for):

Enables autodialing and specifies the smallest [or largest] rate the autodialer will set for the goal, in terms of your goal’s current time unit.

Sometimes, when I change my slope, I also change my time unit.[1]

So when I go from “x per week” to “y per day” and the autodialer was set up with #autodialMin=z, where z refers to a weekly time unit–will the autodialer also convert z to a daily number or will it now force me to do at least “z per week”?

  1. This is mostly because I somehow prefer certain numbers. Let’s say I want to go from “2 per week” to “3 per week”. In that case, I switch a bit between the time units and notice that “3 per week” is “0.42… per day”. And because I like the number four (and because a steeper slope is better), I actually commit to “0.44 per day”. ↩︎

It appears to treat days before the goal was created as 0s, giving a slow ramp-up. I like this a lot.


Yes, that was what I figured out as well. Good solution. :slight_smile:

@ncyrocks Issues should be fixed now!

On new-goal behavior, you guys are right, it does assume 0s before the start of the road. But in addition it also multiplies the difference by the percentage of a month that has elapsed. So if a goal is only 15 days old, it’ll only change the rate half as much as a straight average would dictate, even including 0’s before the start of the road. This is to avoid do-less goals from immediately getting dialed to zero / unit.

1 Like

Just pushed an update so the autodialer now explicitly shows pending rate changes:


This hasn’t been working for me for the last few days - pressing ‘Force Run’ gives a 500 server error. Is that something wrong on my end or is it down?

1 Like

@narthur Don’t know if you’ve seen this - the autodialer hasn’t been working (at least for me) for a week or so now.

1 Like

@ncyrocks Thanks for the heads up! Yes I need to figure out what’s going on here…

1 Like

Ok, I pushed a fix! Can you try it again and let me know if it’s working now?

1 Like

It’s working now! Thanks so much :smiley:

1 Like

@narthur: Does the autodialer respect future breaks?


  • Let’s say I have set a break with the following specs: Set the slope of a goal to 0 from 20 days to 25 days from today.
  • Now, let’s say autodialer changes my slope from 1 to 1.5. This will become effective in a week (or 8 days, I think).
  • Will this update keep the break/plateau at slope 0 from 20-25 days out? Or will it overwrite it?
1 Like

@howtodowtle Yup! It respects future breaks. It only changes the slope of the last segment in your matrix (starting after the akrasia horizon if the last segment intersects it). So any future breaks are preserved.


That’s a very nice behavior, really thought through! :blush:

1 Like

The autodialer now supports adding the #autodial etc tags in the goal’s title (the text right below the slug)! (ht @mufflon)

1 Like

This may or may not have been due to me misunderstanding Beeminder for close to 5 years now :smiley:

1 Like

I have a goal using the autodialer that has dialed itself down to zero, because there had been no data points added in the last thirty days. Which is fine and what I expected it to do. After I added a new data point I expected it would dial itself back up again, which didn’t happen, and I can see why not - it can’t tell the difference between the rate of zero it set itself and a rate of zero that I set as a break. So I guess I should set an #autodialMin=0.0something to keep it working.

Just documenting here in case it helps anyone else - or there’s something I’m missing that someone can let me know!

Huh, that’s interesting… the autodialer doesn’t treat 0 any different than any other rate. The reason it doesn’t mess with breaks is because it only modifies the last segment of the road, not because it identifies breaks based on rate… Perhaps you didn’t add enough data for the average rate to be different enough for the autodialer to make a change? Definitely want to make sure there isn’t a bug here…

Yes, I was going to contact you actually as changing the minimum to 0.01 hasn’t made the autodialer change the line except to change it to 0.01/week. The autodialer was working fine until it changed the line to be flat, and it’s picked up the new minimum I set.

There’s one datapoint, of 1, added in the last 30 days and the goal is set up weekly with autodial max of 1 and a min of 0.01 now (goal is this one). 1/30 days would be 0.033, in weeks that’d be 0.233 so I was expecting it to change the rate up to 0.23ish/week.

1 Like