Halakha for Engineers - When Your Code Runs on Shabbat

Most discussion of technology and Shabbat asks the wrong question. "Can I use my phone on Shabbat?" is closed. The answer is no, settled for decades, and there is no productive conversation downstream of it.

The real question, for those of us who build the systems, is harder: what is the halakhic status of the work our machines do while we rest? The cron job that runs at 03:17 Saturday morning. The server that handles requests through the entire twenty-five hours we are not allowed to touch it. The LLM endpoint that generates responses for users who do not know and do not care that the engineer who deployed it is bound by a four-thousand-year-old prohibition on melakhah.

This is the engineer's she'elah, and it is not adequately addressed by general guides to Shabbat observance, because the people who write those guides do not, as a rule, run production infrastructure.

The framework, briefly

Shabbat halakhah identifies thirty-nine categories of melakhah — labor — derived from the work of building the Mishkan. The categories most relevant for software work are:

• Kotev (writing), and by extension anything that produces persistent text or data

• Mav'ir (kindling), and by extension completing electrical circuits, though the precise halakhic mechanism is debated among twentieth-century poskim

• Boneh and Makeh b'patish (building, and finishing a vessel), which cover installing software, deploying systems, and bringing a thing into its functional form
  Two meta-categories matter even more than these:

• Amirah l'akum, the prohibition on directing a non-Jew to perform work for you on Shabbat

• Grama, indirect causation, where you set something in motion that causes the prohibited result without your direct action
  And one principle hangs over all of it: uvdin d'chol, weekday-like activity. Even when something is technically permitted, it may be forbidden because it violates the spirit of Shabbat, which is rest, not loophole engineering.

The Shabbat clock and what it permits

The foundational precedent for everything that follows is the Shabbat clock — the simple electromechanical timer that switches lights and appliances on and off. Rav Shlomo Zalman Auerbach (1910–1995), one of the great poskim of the twentieth century on technology questions, ruled that timers set before Shabbat are permitted. The act of switching happens on Shabbat, but you set the cause in motion before. You are not directing the machine on Shabbat; the machine is acting on instructions issued during the week.

This is the principle every observant engineer needs to understand, because every cron job, every scheduled task, every CI pipeline that runs while you sleep is structurally a Shabbat clock. You configured it before. It runs on its own. You do not interact with it during Shabbat.

In broad strokes, that is permitted. But the broad strokes are where most people stop, and most people are wrong about the details.

Cron jobs and scheduled work

A cron job that runs Saturday at 04:00, configured the previous Tuesday, is structurally identical to the Shabbat clock. The act on Shabbat is performed by the machine, not by you. You set it in motion days earlier. There is no amirah, because there is no person you are instructing — the machine is your kli, your tool, and a tool is not an agent.

That said, three caveats matter, and they matter more than the permission itself:

1. You cannot benefit from forbidden work. If the cron job exists specifically so you can wake up Saturday morning to a fresh data pipeline you will then use during Shabbat, you have a problem. The benefit you derive on Shabbat from work scheduled before is the boundary case, and it tightens the further you push it.
2. The output cannot be the point of the day. If the system is built such that the value of Shabbat to your business is the work the system does on Shabbat, you are circumventing the prohibition rather than respecting it. Halakhah does not look kindly on architectural patterns that make Shabbat a profit center.
3. L'natchila and b'di'avad are not the same. Many things are permitted after the fact (b'di'avad) that you should not arrange in advance (l'natchila). Deploying code Friday afternoon specifically because you want it to run through Shabbat is not the same as discovering after the fact that something you wrote weeks ago happens to execute during it.

Production services and the on-call problem

Here the halakhah becomes unforgiving. If you carry a pager — physical or virtual — and you are expected to respond to incidents during Shabbat, you have a structural conflict that no amount of clever ruling can dissolve.

You cannot carry the device. You cannot use it. You cannot respond to the alert. You cannot even know the alert exists, because checking the screen is kotev by extension and mav'ir by the act of waking the display.

The honest answer is that being on-call during Shabbat is incompatible with shomer Shabbat status, and the engineer who tries to reconcile them by chasing the maximally permissive ruling is asking the wrong question. The right question is: how do I structure my employment, my team, and my systems so that I am not on-call during Shabbat? This is a career-architecture question, not a halakhic one. The halakhah is clear; what is unclear is whether you are willing to pay the professional cost of taking it seriously.

For most engineers in most companies, the answer is the same answer every observant Jew has negotiated in every non-Jewish workplace for centuries: arrange a Shabbat handoff with a colleague, document it, automate as much fallback as possible, and pay it back by covering Christmas, New Year's, and whatever other days your colleagues need. This is normal. It is not a hardship. It is the cost of being who you are, and it is small.

AI systems and the vending machine principle

The newest version of an old question. You deploy an LLM endpoint Friday afternoon. Through Shabbat, users send requests, the model generates responses, money changes hands.

The halakhic precedent is the vending machine, addressed by Rav Moshe Feinstein and others. A machine you set up before Shabbat, that transacts with customers without your intervention, is broadly permitted, on the same principle as the Shabbat clock — you are not the one acting, the machine is. The customer is not transacting with you on Shabbat; they are transacting with a kli that you configured during the week.

Three conditions tighten this:

1. The machine must be clearly a machine. The customer should not believe they are interacting with a Jew on Shabbat. For an API endpoint, this is structurally satisfied — nobody calling an LLM API thinks they are talking to its operator.
2. You cannot intervene during Shabbat. No deployments, no patches, no monitoring, no incident response. The system must be capable of running for twenty-five hours without you, and if it fails, it fails — you fix it after Havdalah.
3. The economics must not depend on Shabbat. If your business model is structured such that Shabbat is your peak revenue window and you are deliberately exploiting that, you have crossed from permitted operation into deliberate commerce on Shabbat, which is a distinct prohibition.
   The upshot: an LLM you deployed Tuesday that happens to serve traffic on Saturday is fine. An LLM whose entire purpose is generating revenue while you cannot be alerted to its failures is, structurally, weekday work that you have laundered through automation.

The deeper point

There is a temptation — strong, professional, almost reflexive — to treat Shabbat as a system constraint and to engineer around it. This is the wrong frame. Shabbat is not a technical limitation. It is a discipline, and the discipline is the point.

The engineer's question is not "what can I get away with." It is: how do I architect my professional life such that Shabbat is genuinely no work — no monitoring, no thinking about production, no part of me on call? That is a harder question than the halakhic one, because the halakhah is mostly settled and the architectural question is yours to solve every week, in the specifics of your job, your team, and your systems.

If you build well, Shabbat does not require you to fight your infrastructure. The infrastructure runs on its own from before Shabbat begins, and it stops being relevant to you for twenty-five hours, the way the soup on the blech stops being relevant. You eat it because you cooked it before. You did not cook it on Shabbat.

That is the kli. That is the engineer's halakhic responsibility. Build it before. Step away. Trust that you built well.