DevOps Intermediate

AutoSys date_conditions vs run_window: The 2 Rules Engineers Miss

📅 March 19, 2026 ⏱ 3 min read 🎯 Intermediate

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 17 of 30

date_conditions is your master switch.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

date_conditions is your master switch.

date_conditions: 0 = time scheduling OFF. Default. Catches people every time.
date_conditions: 1 = time is an AND gate with conditions, not an OR gate.
run_window for CMD jobs = advisory deadline + alarm, no kill — term_run_time kills.

thecodeforge.io

date_conditions vs run_window

Autosys Date Conditions Run Window

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡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

🚨 START HERE

AutoSys Time Gate Debugging — 60-Second Diagnosis

Run these commands when jobs ignore schedules or run at the wrong times

🟡

No time-based execution

Immediate ActionCheck date_conditions flag

Commands

autorep -J JOBNAME -q | grep date_conditions

autorep -J JOBNAME -q | grep -E "start_times|run_calendar"

Fix Nowupdate_job: JOBNAME date_conditions: 1

🟡

File watcher misses files

Immediate ActionCheck run_window against current time

Commands

autorep -J JOBNAME -q | grep run_window
date +%H:%M

ls -la /path/to/watch_dir/*.dat

Fix Nowupdate_job: JOBNAME run_window: "00:00 - 23:59"

🟡

CMD job hangs past window

Immediate ActionCheck term_run_time value

Commands

autorep -J JOBNAME -q | grep term_run_time

ps -ef | grep process_name

Fix Nowupdate_job: JOBNAME term_run_time: 360

Production Incident

The 3 AM File Watcher That Never Saw the File

A critical file arrived at 2:57 AM — three minutes before the run_window closed. The FW job never saw it. The downstream workflow waited until 8 AM to detect the file, blowing the SLA by five hours.

SymptomThe 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.

AssumptionThe 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 causeFW 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.

FixOption 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 Guide

When jobs don't run when expected — the symptom-to-action map

Job has start_times and days_of_week set but never runs on schedule→Check date_conditions value: autorep -J jobname -q | grep date_conditions. If 0, time scheduling is disabled entirely. Update to 1.

File Watcher job completed with SUCCESS but no files were processed, and files exist in watch_dir→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.

CMD job keeps running past its allowed window and doesn't terminate→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.

Job with run_calendar inserted yesterday runs outside expected dates→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.

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.jil · BASH

1234567891011121314151617181920212223

/* 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 */

Mental Model

The AND Gate Mental Model

date_conditions changes how conditions and time interact — it doesn't replace either.

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.

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.jil · BASH

123456789101112131415161718192021

/* 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.jil · BASH

1234567

/* 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.

🗂 AutoSys Time Gate Attributes — Side by Side

What each attribute actually controls

Attribute	What it does	Applies to job type	Kills the job?
date_conditions: 0	No time schedule — condition/manual trigger only	CMD, BOX, FW	N/A
date_conditions: 1	Enable start_times/days_of_week/run_calendar	CMD, BOX, FW	N/A
run_window	Hours during which job can run / FW can detect	CMD (advisory), FW (enforced)	CMD: No, FW: N/A
term_run_time	Hard-kill job after N minutes	CMD	Yes

🎯 Key Takeaways

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

⚠ Common Mistakes to Avoid

✕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 Questions on This Topic

QWhat is the difference between date_conditions and run_window in AutoSys?Mid-levelReveal
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.
QDoes run_window automatically kill a CMD job when the window closes?Mid-levelReveal
No. For CMD jobs, run_window is advisory only. When a job runs past its run_window, AutoSys raises the max_run_alarm (if configured in the profile) but the job continues executing. To terminate a CMD job after a specific runtime, use term_run_time (value in minutes). Example: run_window: "23:00 - 05:30" with term_run_time: 390 ensures the job is killed 6.5 hours after start, even if it would otherwise run past 5:30 AM.
QHow do you disable time-based scheduling on an existing AutoSys job?JuniorReveal
Use update_job to set date_conditions: 0. This disables all time-based scheduling including start_times, days_of_week, and run_calendar. The job will then run only when triggered by a condition (success/failure of another job) or manually via sendevent. Important: Setting date_conditions: 0 does NOT remove the time attributes from the JIL — they remain stored but are ignored. To clean up, you can also explicitly remove start_times and run_calendar with update_job.
QWhy is run_window important for File Watcher jobs specifically?SeniorReveal
File Watcher jobs enforce run_window strictly. Outside the defined window, the watcher does not scan the watch directory at all. Files that arrive outside the window are completely invisible to the job — they are not queued or remembered. Without run_window, a File Watcher can trigger on stale files at any time of day, causing false downstream processing. With run_window, you can restrict detection to business hours or specific batch windows. This is critical for preventing repeated processing of the same file and for ensuring that SLA-bound files are only detected during their expected arrival windows.
QHow do you set a run_window that spans midnight in AutoSys?JuniorReveal
Use a time range where start time is numerically greater than end time. For example, run_window: "22:00 - 06:00" creates a window from 10 PM to 6 AM the next day. AutoSys automatically interprets start > end as a midnight-spanning window. No special syntax is required. However, test with autorep -J jobname -q to confirm the window string is stored correctly, and verify behavior using a test job with a short window that crosses midnight.
QWhat happens when a Box has a run_window and a child job has its own run_window?SeniorReveal
The child job's run_window overrides the box's window — the job runs only when BOTH its own schedule AND its own window conditions are met, subject to the box's start condition. However, the child cannot start before the box starts, regardless of its run_window. Common pattern: Box has a wide window (e.g., 22:00 - 06:00 overnight). Different child jobs within the box have narrower windows (e.g., job A: 22:00-23:30, job B: 02:00-04:00). Each child respects its own window, but all are confined to the box's overall execution period.

Frequently Asked Questions

What does date_conditions do in AutoSys?

date_conditions is a flag (0 or 1) that enables or disables time-based scheduling for a job. When set to 0 (the default), the job ignores start_times and days_of_week. When set to 1, the job runs according to its time schedule.

Does run_window kill a job when the window closes?

For CMD jobs, run_window doesn't automatically kill the job — it's advisory. You need term_run_time to hard-kill a job after a specified number of minutes. For File Watcher jobs, run_window prevents the watcher from detecting files outside the specified hours.

How do I disable time-based scheduling on an AutoSys job?

Use update_job to set date_conditions: 0. This disables start_times, days_of_week, and run_calendar. The job will only run when triggered by a condition or manually.

What is the difference between run_window and term_run_time?

run_window defines the hours during which a job is allowed to execute. term_run_time specifies the maximum number of minutes a job can run before AutoSys terminates it. For hard-killing hung jobs, use term_run_time.

Can run_window span midnight in AutoSys?

Yes. Run windows like "22:00 - 06:00" correctly span midnight. AutoSys understands that the end time is the following day. This is standard for overnight batch scheduling.

What happens if a File Watcher's run_window closes while it's scanning?

The scan completes if it started before the window closed. The watcher does not abort a scan in progress. However, once the scan finishes, no new scans begin until the next window opens. Files that arrive during the scan are detected in that scan; files that arrive after the scan but before the window closes are detected in the next watch_interval cycle.

🔥

Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged