I built a Telegram bot that sends math questions to kids every day at 2:30 PM Egypt time. It had been live for two weeks, running every single day without a problem, questions going out on time, kids answering, streaks building up. Then recently I ran /admin_health in the bot and saw 0 scheduled questions. That's when I knew something was wrong and went digging through the logs.
The last successful run was April 23. That night, Egypt turned on Daylight Saving Time.
Let me walk you through how the whole thing worked, what broke, and how I fixed it.
How the bot schedules questions
The bot has two main daily jobs:
- 01:30 AM Cairo: prepare today's questions for every user (pick 3 questions based on each kid's weak topics, save them to the database)
- 2:30 PM Cairo: send the first question to everyone
I use a library called node-cron for scheduling. It supports timezones, so I just tell it "run this at 00:30 Cairo time" and it figures out the UTC equivalent automatically.
cron.schedule('30 0 * * *', async () => {
await prepareScheduledQuestions();
}, { timezone: 'Africa/Cairo' });
How "Cairo time" works in the code
The bot server runs on Railway (cloud), so it lives in UTC. Every time I need to know "what day is it in Cairo?", I use this function:
function todayCairoAsUtcMidnight(): Date {
// Get today's date as a string in Cairo timezone, e.g. "2026-04-23"
const dateStr = new Intl.DateTimeFormat('en-CA', {
timeZone: 'Africa/Cairo',
year: 'numeric',
month: '2-digit',
day: '2-digit',
}).format(new Date());
// Return that date as UTC midnight so we can compare with database values
return new Date(dateStr + 'T00:00:00.000Z');
}
So "today in Cairo" becomes a fixed timestamp I can store in the database and compare against later. A question prepared at 01:30 AM Cairo gets tagged with 2026-04-23T00:00:00.000Z. When the 2:30 PM cron runs, it looks up questions tagged with that same date. If they match, the question gets sent.
This works great as long as Cairo is always UTC+2.
What is Daylight Saving Time?
DST is when a country moves its clocks forward by 1 hour in summer to make better use of daylight. Egypt reinstated DST in 2023 after not using it for about 10 years.
In Egypt:
- Last Friday of April at midnight → clocks jump from 00:00 to 01:00 (spring forward)
- Last Thursday of October at midnight → clocks go back from 01:00 to 00:00 (fall back)
The key phrase is "clocks jump from 00:00 to 01:00". That means 00:30 literally does not exist on that night.
The bug
My prepare-questions cron was set to run at 00:30 Cairo time.
On April 24, 2026 (the DST transition day), at midnight Cairo, clocks skipped forward one hour. The time went from 00:00 directly to 01:00. There was no 00:30.
node-cron saw that 00:30 didn't exist that night and silently skipped the job. No error, no warning, nothing in the logs. But it gets worse. After that skip, node-cron's internal scheduler got into a broken state. It was not just the prepare job that stopped. Every single cron job stopped firing. The 2:30 PM send job never ran on April 24. Or April 25. The bot process was alive on Railway, no crashes, no restarts, just complete silence for two days.
Here are the actual logs. Everything stops on April 23:
[2026-04-22T22:30:00.006Z] [INFO] [CRON] Preparing daily questions...
[2026-04-22T22:30:31.408Z] [INFO] Prepared adaptive questions for 9 users
[2026-04-23T12:30:00.025Z] [INFO] [CRON] Sending first question...
[2026-04-23T12:30:25.042Z] [INFO] First question sent {"sent":8,"failed":1,"total":9}
[2026-04-23T17:30:00.016Z] [INFO] [CRON] Sending reminders...
[2026-04-23T17:30:05.120Z] [INFO] Reminders sent {"sent":8,"total":9}
(silence after this)
Notice 22:30 UTC = 00:30 Cairo (UTC+2), and that was the last time questions were prepared. After that, the clocks changed and 00:30 disappeared.
Why there were no errors
This is the sneaky part. node-cron doesn't throw an error when a scheduled time is skipped due to DST. And when the scheduler breaks internally, it also does not throw an error. The bot process just keeps running, healthy from Railway's point of view, with zero indication that all the scheduled work stopped.
No crash to investigate. No alert to wake you up. Just kids not getting their questions.
Fix 1: Move the cron to a safe time
The simplest fix: change 00:30 to 01:30.
Egypt's clocks spring from 00:00 to 01:00, so 01:30 always exists, even on DST transition day. Problem solved.
// Before (broken on DST spring-forward day):
cron.schedule('30 0 * * *', handler, { timezone: 'Africa/Cairo' });
// After (safe):
cron.schedule('30 1 * * *', handler, { timezone: 'Africa/Cairo' });
One more thing: on the fall-back day in October, clocks go from 01:00 back to 00:00, so 01:30 actually happens twice that night. That means the job runs twice. But that is totally fine, because at the start of prepareScheduledQuestions() there is a check: if a user already has questions prepared for today, skip them. So the second run just finds everyone already done and exits. No duplicates, no problems.
Fix 2: Add a fallback inside the send job
The cron time fix handles DST. But what if the prepare job fails for any other reason, like a server hiccup, a deploy at the wrong time, whatever?
I added one line at the top of the send-questions job:
export async function sendFirstQuestion(bot) {
// If questions weren't prepared for any reason, prepare them now before sending
await prepareScheduledQuestions();
// ... rest of the send logic
}
prepareScheduledQuestions() already skips users who have questions today, so calling it here costs nothing on a normal day. But on a broken day, it saves everyone from getting nothing.
The lesson
If your cron jobs use a timezone that observes DST, avoid scheduling at times that get skipped during the spring-forward transition. In Egypt that means avoid 00:01 through 00:59. Use 01:30 or later to be safe.
More generally: cron + timezones is a place where things can go silently wrong. The job doesn't crash, there's no alert, users just don't hear from your app. Always add a fallback or at least an explicit log when your main jobs find zero work to do. That's usually a sign something upstream failed.
if (prepared === 0) {
logger.warn('No questions prepared, double check the prepare-questions job ran today');
}
That one log line would have caught this immediately.
The bot is now fixed and sending questions again. And next April, when Egypt springs forward, it'll handle it quietly.
A question:
Someone may ask: what if you really wanted the job to always run at exactly 00:30 Cairo, no matter what happens to the clock?
Short answer: you can't. Not on spring-forward night.
00:30 Cairo on that night does not exist. The clock jumps from 00:00 directly to 01:00. There is no UTC value that maps to 00:30 Cairo on that specific night. It was erased. No library, no trick, no workaround can schedule something at a time that literally never happens.
The closest you can get is one of two things.
First option is what we already did: move to 01:30. It always exists, even on the transition night. On 364 days a year it runs at 01:30 Cairo. On that one spring-forward night it also runs at 01:30 Cairo, which is just one hour later than you wanted. Not a big deal.
Second option is to schedule at two UTC times, one for winter and one for summer. Winter Cairo is UTC+2, so 00:30 Cairo = 22:30 UTC. Summer Cairo is UTC+3, so 00:30 Cairo = 21:30 UTC. You run both. Since the prepare function skips users who already have questions today, only one of the two actually does any work on a normal night. On the transition night, 22:30 UTC lands at 01:30 Cairo so you again get one hour late, but questions are still prepared. This gets you 00:30 on all regular nights in both seasons.
But honestly the real safety net is the fallback we added inside the send job. Even if the prepare cron runs late, or gets skipped, or breaks entirely, questions get prepared right before they are sent at 2:30 PM. That is what actually protects users, not the exact minute the prepare job fires.