What broke
An hourly timer counts from container start, so it could miss the 16:00 slot
The Instagram posting job ran on a timer that fired once an hour, counted from when the container started. A start at 14:58 meant ticks at 15:58 and 16:58, too early and then too late for the 16:00 UTC slot. The fix was a ten-minute tick.
The short version
What went wrongThe Instagram posting job used an hourly interval timer that counts from container start, so a 14:58 start gave ticks at 15:58 and 16:58 and missed the 16:00 UTC slot.
How we found itThe fix commit recorded the 14:58 start and the 15:58 and 16:58 ticks. No error appeared; the post just came at the wrong time.
The rule nowFor a job tied to a time of day, don't use an interval timer. Tick every ten minutes, let the job check the clock against its slot, and post only once per day.
This post documents something Claude got wrong. The claim rests on a commit or a file, not on memory. All of Claude's mistakes
The engine behind this site does more than write posts. Since 4 October 2026 it also posts to Instagram once a day. The job is meant to run at 16:00 UTC. The timer behind it could not hit that time reliably, and the reason is common enough to be worth writing down.
What the code did
The posting job is a function the engine’s server calls on a timer. According to its comment, each call refreshes the Instagram token and, on a posting day, posts the next carousel once. A flag stops two calls from running at the same time. The posting hour is set to 16 UTC, and the list of posting days covers all seven days of the week.
Claude wrote the scheduling as two lines in the server:
- a one-off call ten minutes after the server starts, so the job runs soon after a deploy
- a repeating call every hour after that
The comment above the function said what it was meant to do: “Called every hour: refreshes the token, and on a posting day posts the next carousel once.”
An “hourly” job feels like it should line up with the hours on a clock, and that is what this setup quietly assumed.
Why it went wrong
A repeating interval timer does not know what time it is. It counts from the moment it is created. That moment is when the process starts, which here means when the container starts.
The fix commit records a concrete case. The container started at 14:58. The hourly timer then fired at 15:58 and again at 16:58.
- At 15:58 it was too early for the 16:00 slot.
- The next chance was at 16:58, almost an hour after the slot.
The commit says it plainly: the timer “ticked at 15:58 (too early) and next at 16:58.” A start a few minutes later would move every tick by the same amount. The posting time was set by the container start time, not by the schedule in the code.
No exception and no failed request appears in the material.
The fix
The fix landed on 4 October 2026, co-authored by Claude. It is a one-line change to the interval plus updated comments:
- The repeating call now runs every ten minutes instead of every hour.
- The one-off call ten minutes after start is unchanged.
- The comment on the function now says “Called every ten minutes”.
- A new comment above the timer gives the reason: an hourly timer counts from container start and could land just before 16:00.
The fix did not change the logic inside the job. Its comment says it posts the next carousel once on a posting day.
Interval timers are not schedules
The general point: “every hour” can mean two different things.
- An interval. Run, wait 60 minutes, run again. The phase, meaning where in the hour the runs land, comes from whenever the timer started.
- A schedule. Run at a time on the clock, such as 16:00. The phase is fixed.
A plain repeating timer in a long-running process gives you the first. If the job has a deadline or a slot, you want the second. You can get it in a few ways:
- Tick often and let the job check the clock. It is simple and survives restarts, and its precision is the length of the tick.
- Work out the time until the next slot and set a one-off timer for it, then set the next one after it fires. This is more exact, but more code to get right.
- Hand the job to a real scheduler outside the process.
The first option is the cheapest when the job is meant to do its work only once per slot.
There is also a restart issue. The timer counts from container start, so every container restart resets the interval’s phase. A system that restarts often gets a different set of tick times after each restart.
Whose mistake
The original scheduling code and its comment were written by Claude. Henning writes no code in these repositories. The fix commit describes the fault in plain terms and carries Claude’s co-author line. The material doesn’t show how the problem was spotted. It records the start time, the two tick times and the fix.
The rule
If a job has to happen at a time of day, don’t schedule it with an interval timer. Run a short tick, let the job compare the clock to its slot, and make sure it does its work only once per slot.