Intuitively it seems like it would be “the clock strikes midnight (or whatever your deadline is) and your datapoint is still in the red”.
But it’s not exactly that, and it’s hard to make it be exactly that because it’s hard to guarantee that a given piece of code runs at a certain exact time.
So what it actually is is “yesterday’s datapoint is red”. If at any time Beeminder notices that that is true then you instantly derail. Normally that happens within seconds or at most minutes after your actual deadline (when it’s officially the new day) and everything is great.
But it can also happen because you, say, edited yesterday’s datapoint, and that’s surprising. Maybe still correct, but surprising.
If I wanted to defend this I’d cite worse-is-better – see the parenthetical towards the end of https://blog.beeminder.com/magic/ – and explain how nice and simple that makes the implementation. Namely, when the deadline hits it becomes officially the new day and we have a dirt-simple check, “red yesterday”, that doesn’t depend on when the check actually happens which in fact can be arbitrarily far after the deadline in case of the queues being backed up or network delays or god-knows-what.
That may not be a good apologia though! “Derails happen only when you hit the deadline while in the red” may be The Right Thing. But how to get there from here? We could get a little closer by defining a window: if it’s not within X minutes of the deadline then let a red datapoint yesterday slide. But that’s ugly and fragile and confusing and magical.
There’s probably a way to have the best of all worlds but we haven’t thought of it yet…