Senior 3 min · March 19, 2026

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.

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • 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
Plain-English First

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.

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_examples.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/* Job that ONLY runs via dependency (no time schedule) */
insert_job: downstream_job
job_type: CMD
command: /scripts/process.sh
machine: server01
owner: batch
date_conditions: 0             /* no time schedule */
condition: success(upstream_job)

/* Job with BOTH a schedule AND a condition */
insert_job: morning_report
job_type: CMD
command: /scripts/report.sh
machine: server01
owner: batch
date_conditions: 1             /* time-based scheduling active */
days_of_week: mon-fri
start_times: "07:00"
condition: success(overnight_etl)  /* also waits for ETL to complete */

/* To remove run_calendar and start_times from a job in JIL: */
update_job: morning_report
date_conditions: 0             /* disables time scheduling entirely */
The AND Gate Mental Model
  • 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.
Production Insight
The silent failure: job has date_conditions: 0 but someone added a run_calendar months ago. The calendar sits in the JIL, ignored, no error. The team thinks the job is scheduled. It never runs.
Diagnosis: autorep -J jobname -q | grep -E "date_conditions|run_calendar|start_times". If date_conditions is 0, time fields exist but are dead.
Rule: When updating jobs, always audit date_conditions after adding time attributes. The default is 0. Many assume it auto-enables — it doesn't.
Key Takeaway
date_conditions is the master switch — 0 means ignore all time fields
1 means time is an active gate that ANDs with conditions
Default is 0. Engineers who forget this watch jobs never run.
Which date_conditions value should you use?
IfJob runs ONLY when another job finishes — no time schedule
Usedate_conditions: 0. Start_times and run_calendar not needed.
IfJob runs at a specific time AND must also wait for upstream jobs
Usedate_conditions: 1. Time gates AND condition gates both apply.
IfJob runs at a specific time regardless of upstream jobs
Usedate_conditions: 1 with no condition attribute. Or use start_times alone.
IfFile Watcher must check continuously, not on a schedule
Usedate_conditions: 0. The watcher runs constantly within its run_window.
date_conditions vs run_window date_conditions vs run_window. Master switch vs execution window · date_conditions · run_window · Binary flag: 0 or 1 · Default is 0 (off) · Must be 1 for start_times THECODEFORGE.IOdate_conditions vs run_windowMaster switch vs execution window date_conditions run_windowBinary flag: 0 or 1Default is 0 (off)Must be 1 for start_timesControls if schedule is activeAlso gates run_calendarTime range for executionCMD: advisory ceilingFW: enforces detection hoursSpans midnight correctlyPrevents stale file triggersTHECODEFORGE.IO
thecodeforge.io
date_conditions vs run_window
Autosys Date Conditions Run Window

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.

run_window_examples.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* File Watcher: only detects files between 8 AM and 6 PM */
insert_job: watch_for_feed
job_type: FW
watch_file: /data/feeds/FEED_*.dat
watch_interval: 30
min_file_size: 1024
machine: file-server
owner: batch
run_window: "08:00 - 18:00"

/* CMD job: must complete within overnight batch window */
insert_job: nightly_reconcile
job_type: CMD
command: /scripts/reconcile.sh
machine: finance-server
owner: batch
date_conditions: 1
days_of_week: all
start_times: "23:00"
run_window: "23:00 - 05:30"    /* window for job execution */
term_run_time: 390             /* hard kill after 6.5 hours */
run_window on CMD jobs does NOT kill
This is the #1 misunderstanding. Autosys raises alarm $MAX_RUN_ALARM when a CMD job runs past run_window, but the process keeps running. Without term_run_time, a hung job can run for days past its window, consuming resources and blocking downstream dependencies that wait on its completion status.
Production Insight
We saw a reconciliation job that ran past its 5:30 AM window every day. The team thought run_window would kill it. Instead, it overlapped with the morning online transaction window — table locks from the job caused 30-second delays on customer orders.
The alarm fired, no one monitored it. The job kept running until 7:45 AM, killed manually by an engineer checking on the slow system.
Fix: add term_run_time: 240 (4 hours). Now the job dies at 3:00 AM if it's still running, well before the transaction window opens.
Rule: run_window without term_run_time is a notification, not a termination.
Key Takeaway
run_window for CMD = advisory deadline + alarm trigger
run_window for FW = enforced detection gate
term_run_time = the actual kill switch
Use all three together for real protection.

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.

midnight_window.jilBASH
1
2
3
4
5
6
7
/* Overnight batch window: 22:00 to 06:00 next day */
insert_job: overnight_batch
job_type: BOX
date_conditions: 1
days_of_week: mon-fri
start_times: "22:00"
run_window: "22:00 - 06:00"    /* correctly handles midnight crossing */
Testing midnight windows
Always test a midnight-spanning window with autorep -J jobname -q after creation. The output shows the raw run_window string — no "next day" indicator. To verify logic, temporarily change the system time or use a test job with a 5-minute window that crosses midnight.
Production Insight
Edge case: run_window "23:00 - 00:30" works — start 23:00, end 00:30 next day. But some engineers write "00:30 - 23:00" thinking it means the same. That window runs for 22.5 hours, not 1.5 hours.
AutoSys evaluates the window as written. If start < end, it's a same-day window. If start > end, it's overnight.
Failure scenario: A job meant to run overnight from 11 PM to 1 AM had run_window "01:00 - 23:00" (typo, swapped start and end). The job ran for 22 hours, overlapping day shifts, causing contention on shared resources.
Rule: Always check your window direction. If you mean overnight, start time must be LATER than end time numerically.
Key Takeaway
start > end = midnight-crossing window
start < end = same-day window
Test with a 10-minute window before deploying overnight schedules.
Swap start/end by accident and your job runs all day.
● Production incidentPOST-MORTEMseverity: high

The 3 AM File Watcher That Never Saw the File

Symptom
The file watcher job status shows SUCCESS with zero files processed, but the file exists on disk. No errors in the job log. The condition that depends on this file never triggers.
Assumption
The team assumed run_window only applies to CMD jobs — they didn't realise FW jobs enforce the window strictly. They thought the watcher would detect "late" files immediately when the next window opened.
Root cause
FW jobs check for files ONLY when the current system time falls inside run_window. If a file arrives at 2:57 AM and run_window ends at 3:00 AM, the watcher will see it ONLY if it runs its watch_interval check between 2:57 and 3:00. After 3:00, the watcher stops checking entirely — the file might as well not exist until the next day's window.
Fix
Option 1: Extend run_window to 06:00 to cover the full overnight batch window. Option 2: Set date_conditions: 0 on the FW job so it runs continuously, then add a condition that checks file age before triggering downstream jobs. Option 3: Split the FW job from the schedule — use sendevent -E FORCE_STARTJOB to trigger it manually when the file is confirmed present.
Key lesson
  • 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.
Production debug guideWhen jobs don't run when expected — the symptom-to-action map4 entries
Symptom · 01
Job has start_times and days_of_week set but never runs on schedule
Fix
Check date_conditions value: autorep -J jobname -q | grep date_conditions. If 0, time scheduling is disabled entirely. Update to 1.
Symptom · 02
File Watcher job completed with SUCCESS but no files were processed, and files exist in watch_dir
Fix
Check run_window on the job. If current time is outside the window, the watcher never looked. Check autorep -J jobname -q | grep run_window. Compare with current time.
Symptom · 03
CMD job keeps running past its allowed window and doesn't terminate
Fix
run_window is advisory for CMD jobs — it doesn't kill. Check term_run_time. If not set, the job runs indefinitely. Add term_run_time in minutes.
Symptom · 04
Job with run_calendar inserted yesterday runs outside expected dates
Fix
run_calendar requires date_conditions: 1. If date_conditions was 0 when calendar was added, the calendar is stored but ignored. Update date_conditions to 1.
★ AutoSys Time Gate Debugging — 60-Second DiagnosisRun these commands when jobs ignore schedules or run at the wrong times
No time-based execution
Immediate action
Check date_conditions flag
Commands
autorep -J JOBNAME -q | grep date_conditions
autorep -J JOBNAME -q | grep -E "start_times|run_calendar"
Fix now
update_job: JOBNAME date_conditions: 1
File watcher misses files+
Immediate action
Check run_window against current time
Commands
autorep -J JOBNAME -q | grep run_window date +%H:%M
ls -la /path/to/watch_dir/*.dat
Fix now
update_job: JOBNAME run_window: "00:00 - 23:59"
CMD job hangs past window+
Immediate action
Check term_run_time value
Commands
autorep -J JOBNAME -q | grep term_run_time
ps -ef | grep process_name
Fix now
update_job: JOBNAME term_run_time: 360
AutoSys Time Gate Attributes — Side by Side
AttributeWhat it doesApplies to job typeKills the job?
date_conditions: 0No time schedule — condition/manual trigger onlyCMD, BOX, FWN/A
date_conditions: 1Enable start_times/days_of_week/run_calendarCMD, BOX, FWN/A
run_windowHours during which job can run / FW can detectCMD (advisory), FW (enforced)CMD: No, FW: N/A
term_run_timeHard-kill job after N minutesCMDYes

Key takeaways

1
date_conditions
0 = time scheduling OFF. Default. Catches people every time.
2
date_conditions
1 = time is an AND gate with conditions, not an OR gate.
3
run_window for CMD jobs = advisory deadline + alarm, no kill
term_run_time kills.
4
run_window for FW jobs = enforced detection gate. Outside window = files invisible.
5
Midnight windows
start > end means overnight. Swap them and your job runs all day.
6
Always test time gates with autorep -q and a short test window before production.

Common mistakes to avoid

4 patterns
×

Assuming run_window kills CMD jobs

Symptom
A CMD job starts at 23:00, run_window ends at 05:30. The job hangs at 05:31. AutoSys raises alarm $MAX_RUN_ALARM but the job continues running, blocking resources and downstream dependencies until manually killed.
Fix
Add term_run_time to the job: term_run_time: 360 (6 hours). The job terminates 360 minutes after start, regardless of run_window.
×

Using date_conditions: 0 while expecting start_times to work

Symptom
Job has start_times: "07:00" and days_of_week: mon-fri but never runs. autorep shows date_conditions: 0. The time fields are stored but completely ignored.
Fix
update_job: jobname date_conditions: 1. Then verify with autorep -q.
×

No run_window on File Watcher jobs

Symptom
A file watcher detects a stale file at 3:00 AM that was written at 6:00 PM the previous day. The watcher triggers downstream jobs unnecessarily, causing false alerts and repeated processing of old data.
Fix
Add run_window matching business hours. For a watcher that should only detect files during the overnight batch: run_window: "22:00 - 06:00"
×

run_window start/end swapped for overnight windows

Symptom
Intended overnight window 23:00 - 01:00 but run_window is "01:00 - 23:00". The job runs for 22 hours instead of 2, overlapping day-time production workloads and causing contention.
Fix
For overnight windows, ensure start time > end time numerically. run_window: "23:00 - 01:00" not the reverse.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
What is the difference between date_conditions and run_window in AutoSys...
Q02SENIOR
Does run_window automatically kill a CMD job when the window closes?
Q03JUNIOR
How do you disable time-based scheduling on an existing AutoSys job?
Q04SENIOR
Why is run_window important for File Watcher jobs specifically?
Q05JUNIOR
How do you set a run_window that spans midnight in AutoSys?
Q06SENIOR
What happens when a Box has a run_window and a child job has its own run...
Q01 of 06SENIOR

What is the difference between date_conditions and run_window in AutoSys?

ANSWER
date_conditions is a binary flag (0 or 1) that enables or disables all time-based scheduling for a job. When 0, start_times, days_of_week, and run_calendar are ignored. When 1, time scheduling is active and ANDs with any condition dependencies. run_window defines the hours during which a job may execute. For CMD jobs, it's advisory — AutoSys raises an alarm if the job exceeds the window but does not terminate it. For File Watcher jobs, it's enforced — the watcher ONLY detects files within the window. The key distinction: date_conditions controls whether time is considered at all. run_window controls the boundaries when time is active.
FAQ · 6 QUESTIONS

Frequently Asked Questions

01
What does date_conditions do in AutoSys?
02
Does run_window kill a job when the window closes?
03
How do I disable time-based scheduling on an AutoSys job?
04
What is the difference between run_window and term_run_time?
05
Can run_window span midnight in AutoSys?
06
What happens if a File Watcher's run_window closes while it's scanning?
COMPLETE GUIDE
The Complete AutoSys Workload Automation Guide for Engineers →

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.

🔥

That's AutoSys. Mark it forged?

3 min read · try the examples if you haven't

Previous
AutoSys Global Variables
17 / 30 · AutoSys
Next
AutoSys Job Status Codes Explained