It didn't fail. It's still running.
Demos die on the model. Production dies on the operating system. A job that works perfectly when you run it by hand can fail three different ways the moment a scheduler starts it with nobody watching — and the worst of them produces no error, no exit code and no log line at all. Configure a job below and find out which layer kills it, and why the obvious fix doesn't work.
Honest-AI note. No model, no vendor names — the mechanisms here are the same on every modern operating system even as the product names change. The outcome, including whether the job hangs, is derived from the configuration rather than looked up. The one worth internalising: an in-process timeout cannot interrupt a call that is waiting on a permission decision. Two rounds of "just add a timeout" were spent before that was understood.
Configure the job
What happens when the scheduler starts it
Plain-language key (responsible process, grant, protected folder, uninterruptible call)
- Responsible process
- The binary the system holds accountable for a permission. Not the script — whatever launched it.
- Grant
- A permission a human granted once, by clicking a box. It is attached to a specific binary at a specific location.
- Protected folder
- Somewhere the system requires explicit permission to read: synced documents, mail, messages, calendars.
- Uninterruptible call
- An operation that cannot be cancelled by your own alarm or signal. You cannot time it out; you can only avoid making it.