The Gap Your Bot Opens on Shabbat

Rosh Hashanah falls on Saturday, September 12 this year, and the run-up has started. Between now and Erev Yom Kippur on the 20th, every Israeli business owner running an automated WhatsApp line, an AI answering service, or a scheduled reminder sequence will ask the question they ask every Elul: should I turn it off for the chagim?

Most people answer by feel, and most get it wrong in both directions at once. They shut down the wrong things, leave the wrong things running, and never look at what it cost them. So it is worth starting with what the weekend actually looks like.

What Saturday actually looks like

WhatsApp traffic to a small business in Israel does not stop for the weekend. Friday is quieter than a weekday, and Saturday is quieter still. That low Saturday volume is exactly what people use to justify pulling the plug. But quiet is not zero: every Saturday, people pick up their phone on Shabbat and write to a business expecting it to matter.

When Shabbat-observant customers do write, most of them wait until it is out. Motzei Shabbat evening is when people come out of the day and clear the list of things they meant to deal with, so the messages tend to bunch up in the hours after havdalah.

None of that is surprising. What matters is what happens on the other end.

The part that should worry you

The more useful question is how long a customer who writes first waits for a reply. Take a hypothetical business that answers weekday messages within minutes. On Friday afternoon, as everyone closes out, the same message can wait hours. A message sent on Shabbat waits until Saturday night at the earliest, and often until Sunday.

That gap is entirely self-inflicted. Not a technology limit, not a staffing budget. It is what happens when a business decides, reasonably, that nobody is working, and then does nothing else about it. A customer who writes on Saturday evening may not hear back until Sunday, by which point they have often written to somebody else too.

And the part that is easy to miss is Friday. The Shabbat gap is the one everybody talks about. The Friday-afternoon slowdown, when the week winds down early, is the one quietly costing people money.

Tishrei is about to concentrate the problem

Between Erev Rosh Hashanah and Simchat Torah there are five full-closure days in Israel: the two days of Rosh Hashanah on September 12 and 13, Yom Kippur on the 21st, the first day of Sukkot on the 26th, and Shmini Atzeret on October 3.

Three of those five fall on a Shabbat, which sounds like a mercy and mostly is. The exception is the one that breaks systems. Rosh Hashanah’s two days land on Shabbat and Sunday, so the no-send period opens at candle lighting on Friday, September 11, and does not close until havdalah on Sunday night the 13th. In my own calendar table, that window is stored as a single block of 49.2 hours. Every other closure in Tishrei is 25.3 hours. No weekly rule can express the difference.

So the honest framing of the chag question is not “should I be available.” It is: given that you are deliberately unavailable, what does the customer experience while they wait, and does your automation know when the waiting is supposed to end? That second half is where almost everything breaks.

Your bot does not know when Shabbat starts

Nearly every system I have inherited from another developer handles Shabbat the same way: a hardcoded window. No sending between Friday 18:00 and Saturday 20:00. It is a reasonable first guess and it is wrong for most of the year.

Candle lighting in Tel Aviv this year runs from 19:31 at the end of June down to 16:15 in early December — a swing of more than three hours. Against that, a fixed 18:00 cutoff is nearly two hours too late in December, so your reminder sequence fires well into Shabbat every winter Friday. The city matters too: the customary offset before sunset is 40 minutes in Jerusalem, 30 in Haifa, 20 in Tel Aviv. If your customer list spans the country and your window does not, somebody is getting a message they should not.

Then Tishrei arrives and the fixed window collapses. Sukkot has yom tov at both ends with six chol hamoed days in the middle, when normal business is entirely fine. A day-of-week rule cannot tell those apart either.

When I rebuilt this for my own sending engine, the fix was to stop guessing and calculate: candle lighting from actual sunset minus the city’s offset, havdalah from the sun reaching 8.5 degrees below the horizon, and the Hebrew calendar supplying yom tov dates so consecutive festival days merge into one window instead of two. The default city is Jerusalem, deliberately — earliest candle lighting in the country, so if you are wrong you are wrong in the stricter direction. And the windows are stored rather than computed on demand: if the calendar refresh fails, the engine keeps what it has and never deletes. A stale window is a nuisance. A window that silently disappears is a phone call from an angry customer.

The part nobody tests: Motzei Shabbat

Here is the failure I did not see coming, and the one I would check first if I were you.

My sequences originally implemented Shabbat as a hold: a message due inside the blackout simply did not send. Sensible. What I had not thought through is havdalah, when the window lifts and every held message becomes due at the same instant. The customer owed one reminder at 3pm Saturday gets it just after 8pm, along with everyone else’s, in a burst that looks exactly like a spam campaign — to the recipient and to Meta.

The fix was to turn holding into rescheduling. A message landing inside a no-send window gets pushed to the next clear day at the same hour, and the check repeats until the slot is genuinely open. I re-ran it against the live scheduler this morning: a step due Saturday, August 29 at 19:00 moves to Sunday the 30th at 19:00, and a step due Saturday, September 12 at 19:00 — inside the 49-hour Rosh Hashanah block — moves all the way to Monday the 14th, stepping over both festival days instead of dumping at the end of them.

That second case is the one worth picturing. Two days of held messages releasing simultaneously on Sunday night is not a technical hiccup. Section 30A of the Communications Law — the spam law — lets a recipient claim statutory damages of up to ₪1,000 per message without proving any harm, and a simultaneous burst is precisely the pattern that generates complaints.

What to actually do before September 11

Three checks, in order of how much they will hurt if you skip them.

Is your Shabbat window a hardcoded time or a calculated one, and does it know about yom tov at all? If your developer cannot answer in one sentence, assume it is hardcoded and assume Rosh Hashanah will break it.

What does your system do with messages that come due inside the window — hold, or reschedule? If nobody knows, it holds, and you are going to have a very loud Motzei Chag.

What does the customer see during the gap? Not a promise you will answer in five minutes, which you will not, but something true: that you are closed for the chag, when you are back, and what to do if it genuinely cannot wait. A day of silence is survivable. A day of silence after an automated “we’ll get right back to you” is not.

I run one of the small custom-bot studios serving Israeli businesses, Achiya Automation, and among that group the consensus has landed in the same place: the calendar logic deserves more engineering attention than the conversation logic. A bot that phrases something awkwardly is forgivable. A bot that sends a sales message during Kol Nidre is not.

One question I have not settled. For those of you who close completely for the chagim: do you put the real return date in the away message, or do you leave it vague on purpose? I have seen both, and I genuinely do not know which one loses fewer customers.

Updated on 1 October 2026: the article was revised.