AutoSys run_window — Why File Watchers Miss Valid Files
File arrives at 2:57 AM, run_window ends at 3:00 — watcher shows SUCCESS with zero files.
20+ years shipping production infrastructure and CI/CD at scale. Lessons pulled from things that broke in production.
- date_conditions is the master switch: 0 disables all time-based scheduling, 1 enables start_times, days_of_week, and run_calendar
- run_window defines the execution deadline: FW jobs stop detecting files outside it, CMD jobs keep running
- term_run_time kills long-running CMD jobs — run_window doesn't
- Midnight-spanning windows work natively: "22:00 - 06:00" means next day, no extra config
- Production failure: Missing run_window on FW jobs triggers on stale files at 3 AM, filling logs with false alerts
date_conditions is the master switch for time-based scheduling. run_window is the closing time — the job has to be done before the window shuts. Together, they give you precise control over when jobs are allowed to run.
Two attributes that beginners often misuse: date_conditions and run_window. They sound related but do different things.
date_conditions toggles whether time scheduling is even active. Set it to 0, and start_times is ignored entirely — only conditions or manual triggers run the job. Set it to 1, and your schedule kicks in.
run_window is a deadline, not a kill switch. For CMD jobs, AutoSys raises an alarm when the window closes but won't terminate the job unless you also set term_run_time. For File Watcher jobs, the window is strict — no file detection outside those hours. That difference trips up teams constantly.
Why File Watchers Miss Valid Files
AutoSys run_window is a date condition that restricts job execution to a specific time window, defined by a start time and an end time. The core mechanic: if a job's scheduling conditions are met but the current time falls outside the run_window, the job is held until the window opens. It does not retry or re-evaluate the triggering condition — it simply waits. This is critical for file watchers: a job triggered by a file arrival event (using the 'f' condition) will only start within its run_window. If the file arrives outside the window, the job stays in a 'SUCCESS' or 'TERMINATED' state and never processes that file. The window is evaluated at job start time, not at file arrival time. In practice, use run_window to enforce business hours, maintenance windows, or SLA boundaries. It is not a scheduling filter — it is a gate. Teams misuse it as a retry mechanism, leading to silently dropped file events.
date_conditions deep dive
date_conditions is binary — 0 or 1. When it's 0 (the default), the job has no time-based schedule. It only runs when explicitly triggered: manually via sendevent, or by a condition (another job's success/failure) evaluating to true.
When date_conditions is 1, the job has a time-based schedule AND can also have conditions. It runs when its time conditions are met AND its dependency conditions (if any) are all true.
Here's the piece that confuses people: setting date_conditions to 1 does NOT override conditions. The job still waits for its condition dependencies. The time schedule just adds another gate.
- date_conditions: 0 → Time = always true. Only conditions matter.
- date_conditions: 1 → Time = active gate. Must be true AND all conditions true.
- Neither setting makes conditions go away — they're always evaluated.
- If you want time OR conditions (not AND), you need two separate jobs with an OR dependency box.
run_window — the execution window
run_window defines the hours during which a job is permitted to run. It works differently depending on job type.
For CMD jobs: If the job starts and is still running when the window closes, AutoSys raises a max_run_alarm (if configured) but doesn't automatically kill it — term_run_time does that. The window is advisory: a polite suggestion, not a hard stop.
For File Watcher jobs: The watcher only looks for files during the run_window. Outside the window, it won't detect files even if they're present. This is the most important use of run_window — it's enforced, not advisory.
For Box jobs: run_window applies to the box itself. Jobs inside the box inherit the box's window only if they don't have their own run_window defined.
Midnight-spanning windows
run_window windows that span midnight (e.g., "22:00 - 06:00") work correctly in AutoSys — the end time next day is understood automatically. This is common for overnight batch windows.
No special syntax needed. Just write the start time and end time. AutoSys compares current time against the window logically: if start > end, the window crosses midnight.
The Real Reason Your Window Ignored the Calendar
You slapped `date_conditions: 1` on a job and assumed it would only run on the 15th. Then it ran on the 14th. Then it didn't run on the 15th. Now you're blaming Autosys.
Stop. The problem isn't the date condition — it's the combination of calendar resolution and start_time. Autosys resolves start_time against the job's defined calendar, not the system clock. If your calendar says 'every Monday' but your start_time is 00:05, and the job lands on a holiday, the window opens but no run happens. The box stays green. Zero alarms.
Here's the fix: always pair date_conditions with an explicit run_calendar or a condition that references a predecessor. Never let a date-conditioned job fly solo unless you've tested it with the exact calendar entry. And if you're using start_mins, remember it's relative to start_time, not absolute — that's the silent killer.
run_calendar, Autosys uses the system default calendar — which includes weekends and holidays. Your 'first-of-month' job just ran on January 1st because nobody told it to skip New Year's Day.What the Manual Won't Tell You About Overlapping Windows
You've got two jobs in a box. Both have run_window: 01:00 - 02:00. One runs at 01:05, the other at 01:10. The box triggers at 01:00. Both windows open simultaneously. But only the first finishes. The second sits in ACTIVATED state until 02:00, then gets skipped because the window closed while it was waiting for resources.
This is the overlapping window problem. The manual says 'windows are independent per job.' That's true but useless. What matters is that Autosys evaluates the window at job start time, not job end time. If the window closes while the job is in queue, the job is marked as skipped — not failed, not terminated. You get no alert. The SLA report shows 'completed' because it was never in an error state.
Solution: stagger start times by at least your worst-case job duration. Or use max_run_alarm to catch jobs that overstay. Better yet, set run_window on the box level, not the individual jobs, and let the box handle the scheduling.
run_window as a deadline rather than a start window. Set it to the latest safe completion time, then rely on start_mins to spread execution. That way, the window only kills jobs that are already late.How to Abuse run_window for Self-Healing Pipelines
Your batch job ran for six hours instead of two. The window closed at 03:00, but the job kept writing to disk until 08:00. Then your 09:00 cleanup job failed because the files were still locked. You had a zombie process orphaned by a skipped job.
Autosys doesn't kill processes when a window closes. run_window only prevents new job starts. If the job is already running when the window closes, it continues to completion — or until you sendevent -E FORCE_STARTJOB something to kill it.
Here's the pattern that saved my ass three times last year: set the run_window to match your maximum allowed processing time. Then add a job that runs five minutes after window close that checks process tables and kills anything still alive. Pair it with max_exit_success: 1 on the zombie killer so it only runs if the parent job is still running.
It's not elegant. It's not in the docs. But it stops a three-hour fire drill every time a job decides to take a nap.
kill -9 on Autosys jobs can leave your temp files in an indeterminate state. Always use a grace period: kill with SIGTERM first, wait 30 seconds, then SIGKILL. That five-line script will save your weekend.The 3 AM File Watcher That Never Saw the File
- run_window for FW jobs is a detection gate — files outside the window are invisible, not queued.
- Always test edge arrival times against the run_window boundary using a file with a timestamp 1 minute before close.
- For SLA-critical files, add a second FW job with a wider window or remove date_conditions entirely and rely on file age logic.
autorep -J JOBNAME -q | grep date_conditionsautorep -J JOBNAME -q | grep -E "start_times|run_calendar"Key takeaways
Common mistakes to avoid
4 patternsAssuming run_window kills CMD jobs
Using date_conditions: 0 while expecting start_times to work
No run_window on File Watcher jobs
run_window start/end swapped for overnight windows
Interview Questions on This Topic
What is the difference between date_conditions and run_window in AutoSys?
Frequently Asked Questions
JIL syntax, sendevent, autorep, box jobs, file watchers, scheduling, HA, security, cloud workload automation, and 22 interview questions — the definitive AutoSys reference for production engineers.
20+ years shipping production infrastructure and CI/CD at scale. Lessons pulled from things that broke in production.
That's AutoSys. Mark it forged?
5 min read · try the examples if you haven't