Senior 3 min · March 19, 2026

AutoSys date_conditions: Why Your Scheduled Job Never Fires

date_conditions defaults to 0, silently ignoring start_times and days_of_week.

N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Everything here is grounded in real deployments.

Follow
✓ Production
production tested
May 24, 2026
last updated
1,554
articles · all by Naren
 ● Production Incident 🔎 Debug Guide ⚙ Triage Commands
⚡Quick Answer
  • date_conditions: 1 must be set for start_times and days_of_week to take effect; defaults to 0
  • start_times lists clock times; days_of_week filters days; both need date_conditions: 1
  • run_window bounds job completion window but does not terminate — use term_run_time for a hard kill
  • timezone attribute overrides server timezone for multi-region schedules
  • start_mins provides sub-hourly scheduling without listing every hour
  • The first thing to check when a job doesn't run: date_conditions value
✦ Definition~90s read
What is AutoSys Job Scheduling and Time Conditions?

AutoSys date_conditions is a boolean attribute that acts as a gatekeeper for time-based scheduling. When set to 1 (true), the job will not fire until both its time conditions (like start_times, days_of_week, or run_window) are satisfied, regardless of any job dependencies.

★
Scheduling an AutoSys job is like programming a coffee maker — you tell it which days to run, what time to start, and whether it should wait for other things to happen first before brewing.

This is the single most common reason a job appears to 'never fire' — if date_conditions is 0 (the default), the job ignores all time-based attributes and runs solely on dependency resolution. The attribute exists to decouple time-based scheduling from event-driven triggers, letting you mix both paradigms in a single job definition.

Time conditions themselves are evaluated against the job's start_times (a list of HH:MM values) and days_of_week (0-6, Sunday=0). But here's the trap: start_times alone is not enough. Without date_conditions: 1, those times are silently ignored.

The run_window attribute adds another layer — it defines a time window (e.g., "06:00-22:00") during which the job is allowed to start. If the job's dependencies resolve outside that window, it waits until the next window opens, which can look like a hang.

Timezone handling is another pitfall: AutoSys uses the timezone of the job's machine definition by default, not the client's local time, so a job scheduled for 9 AM in New York might fire at 9 AM UTC if the agent is in London.

When combining time conditions with job dependencies, the job must satisfy both: all upstream jobs must complete successfully, AND the time conditions must be met. This creates a logical AND gate. A common mistake is assuming dependencies override time conditions — they don't.

If a job has date_conditions: 1 and a start_times of "14:00", but its upstream job finishes at 13:00, the downstream job will not fire until 14:00. Conversely, if the upstream finishes at 15:00, the job fires immediately (since the time condition is already satisfied).

Understanding this interaction is critical for debugging jobs that seem to 'miss' their window.

Plain-English First

Scheduling an AutoSys job is like programming a coffee maker — you tell it which days to run, what time to start, and whether it should wait for other things to happen first before brewing.

Time-based scheduling in AutoSys is controlled by a small set of attributes that work together. The most important thing to understand up front: date_conditions must be set to 1 for any time-based scheduling to take effect. Without it, start_times and days_of_week are ignored entirely.

Why Your AutoSys Job Never Fires: The Truth About date_conditions

AutoSys date_conditions is a job attribute that, when set to 1, tells the scheduler to evaluate calendar-based rules (start_days, run_calendar, exclude_calendar) before allowing a job to start. Without it, the job ignores all date constraints and runs purely on time or event triggers. This is the single most common reason a scheduled job silently never runs: the attribute defaults to 0.

When date_conditions=1, the job will only fire if the current date matches the defined start_days (e.g., Mon, Wed) or falls within a run_calendar, and is not excluded by an exclude_calendar. The time condition (start_times) is evaluated separately — both must be satisfied. A job with start_times set but date_conditions=0 will run on any day at those times, which is often not what teams intend.

Use date_conditions whenever a job must run on specific days or follow a business calendar (e.g., month-end, weekdays only). In production, forgetting this flag causes jobs to run on weekends or holidays, or worse, never run at all because the operator assumed the calendar alone was sufficient. Always verify date_conditions is 1 when you see a job with start_days or run_calendar defined.

Default Is Off
date_conditions defaults to 0. If you set start_days but forget date_conditions=1, the job ignores the day rules entirely and may run every day — or never, depending on other conditions.
Production Insight
A team scheduled a month-end financial report using run_calendar but left date_conditions=0. The job ran every night at midnight, corrupting the report data for 27 days until the error was caught.
Symptom: job runs at correct time but on wrong days — or never runs despite correct calendar setup.
Rule: Always set date_conditions=1 when using any calendar or start_days; treat it as a mandatory pair.
Key Takeaway
date_conditions=1 is required for any day-based scheduling — it is not implied by setting start_days or run_calendar.
A job with date_conditions=0 ignores all calendar rules and runs purely on time or event triggers.
Always validate both date_conditions and start_times together in your JIL; missing either causes silent failures.
Time-Based Scheduling Flow Time-Based Scheduling Flow. How date_conditions gates the schedule · date_conditions: 1 · master switch — must be ON · days_of_week: mon-fri · which days to run · start_times: 02:00 THECODEFORGE.IOTime-Based Scheduling FlowHow date_conditions gates the schedule date_conditions: 1master switch — must be ON days_of_week: mon-friwhich days to run start_times: 02:00clock time to trigger run_calendar checkoptional — skip holidays condition checkoptional — dependency must be met Job startsall gates passedTHECODEFORGE.IO
thecodeforge.io
Time-Based Scheduling Flow
Autosys Job Scheduling Time Conditions

The date_conditions gate

date_conditions is a binary flag. When it's 1, AutoSys respects the time-based scheduling attributes (start_times, days_of_week, run_calendar). When it's 0 (the default), the job only runs when explicitly triggered — either manually or by a condition from another job.

date_conditions.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* Job that ONLY runs when triggered by another job */
insert_job: load_to_warehouse
job_type: CMD
command: /scripts/load.sh
machine: server01
owner: batch
date_conditions: 0             /* time-based scheduling OFF */
condition: success(transform)  /* runs when transform succeeds */

/* Job with both time AND condition */
insert_job: morning_extract
job_type: CMD
command: /scripts/extract.sh
machine: server01
owner: batch
date_conditions: 1             /* time-based scheduling ON */
days_of_week: mon-fri
start_times: "06:00"
condition: done(overnight_backup)  /* also waits for backup to be done */
date_conditions: 0 is the default
If you define a job without date_conditions, it defaults to 0 and will never run on a schedule. This catches many beginners off guard — always explicitly set date_conditions when you want time-based scheduling.
Production Insight
date_conditions: 0 is the default. Forgetting this means your start_times are dead code.
Always explicitly set date_conditions: 1 for any time-triggered job.
Rule: if a job never runs on schedule, date_conditions is your first suspect.
Key Takeaway
date_conditions gates all time scheduling.
Default is 0 — time conditions ignored.
Punchline: set it to 1 or your schedule is a ghost.

start_times and days_of_week

start_times specifies when to run, days_of_week specifies which days. You can list multiple start times separated by commas. days_of_week accepts values like all, mon-fri, or specific days. Both require date_conditions: 1.

time_scheduling.jilBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* Run once daily at 2 AM, all days */
date_conditions: 1
days_of_week: all
start_times: "02:00"

/* Run twice daily on weekdays only */
date_conditions: 1
days_of_week: mon-fri
start_times: "08:00, 20:00"

/* Run on specific days */
date_conditions: 1
days_of_week: mon,wed,fri
start_times: "12:00"

/* Run every 15 minutes (use with caution in production) */
date_conditions: 1
days_of_week: all
start_mins: "00,15,30,45"   /* start_mins for sub-hourly */
Production Insight
Multiple start_times can cause overlapping runs if the previous run exceeds the interval.
Use start_mins for sub-hourly instead of listing 96 entries.
Production rule: always set max_run_alarm or term_run_time for tight schedules.
Key Takeaway
start_times lists clock times; days_of_week filters days.
Both are ignored without date_conditions: 1.
Punchline: time scheduling is gated — verify the gate first.

run_window — bounding when a job can run

run_window defines a time range within which the job must complete. If the job is still running when the window closes, AutoSys generates an alarm. Some configurations also terminate the job at the window end, but only if term_run_time is set.

run_window.jilBASH
1
2
3
4
5
6
7
8
9
10
insert_job: batch_processing
job_type: CMD
command: /scripts/batch.sh
machine: server01
owner: batch
date_conditions: 1
days_of_week: all
start_times: "23:00"
run_window: "23:00 - 06:00"    /* must complete within this window */
term_run_time: 420             /* kill after 7 hours regardless */
Production Insight
run_window only alarms at window close by default. It does not kill the job unless term_run_time is set.
Use term_run_time to hard-kill if the window must not be exceeded.
Common mistake: assume run_window stops the job — it doesn't by itself.
Key Takeaway
run_window bounds the execution window.
It alarms but does not terminate unless term_run_time is set.
Punchline: add term_run_time if you need a hard cutoff.

Timezone handling

By default, AutoSys uses the server's timezone. For jobs that must run at a specific local time regardless of server timezone (common in multinational companies), set the timezone attribute explicitly.

timezone.jilBASH
1
2
3
4
5
6
7
8
9
insert_job: london_end_of_day
job_type: CMD
command: /scripts/london_eod.sh
machine: london-server
owner: batch
date_conditions: 1
days_of_week: mon-fri
start_times: "18:00"
timezone: Europe/London        /* runs at 18:00 London time always */
Production Insight
Timezone mismatch is silent and hard to trace. The job appears to run at the wrong time.
Use the timezone attribute explicitly, especially for multi-region deployments.
Verify server timezone vs job timezone with the date command and autorep.
Key Takeaway
Timezone attribute overrides server timezone.
Without it, jobs run at server local time — not your expectation.
Punchline: always set timezone if regional time matters.

Combining time conditions with job dependencies

You can mix date_conditions with condition dependencies. The job starts when both the time condition is met AND the dependency is satisfied. This is common for batch pipelines that must run at a specific time only if upstream succeeded.

time_and_condition.jilBASH
1
2
3
4
5
6
7
8
9
insert_job: nightly_etl
job_type: CMD
command: /scripts/etl.sh
machine: server01
owner: batch
date_conditions: 1
days_of_week: mon-fri
start_times: "02:00"
condition: success(data_load)   /* runs at 2am only if data_load succeeded */
Production Insight
If the time condition and dependency conflict (e.g., dependency never true), the job sits in ACTIVATED state forever.
Use autorep -d to check why the job hasn't started.
Rule: design time conditions to be permissive if the dependency is the primary driver.
Key Takeaway
Time + dependency = job runs when both are satisfied.
If one never fires, the job stalls.
Punchline: make time conditions a safety net, not a gate.

Common time scheduling failures and debugging

Even with correct settings, jobs may fail due to server time drift, unexpected daylight saving transitions, or missing calendars. Use autorep -q to verify job definition and autorep -d to see why a job hasn't started. Always check system time with the date command on the AutoSys server.

debug_commands.shBASH
1
2
3
4
5
6
7
8
9
10
11
# Check job definition
$ autorep -q my_job | grep -E "date_conditions|start_times|days_of_week|timezone"

# Check job status and why it hasn't started
$ autorep -d my_job

# Check server time
$ date

# Check for pending conditions
$ autorep -d my_job | grep -i condition
Production Insight
Time drift of even a few seconds can cause missed windows in tightly scheduled environments.
Use NTP synchronisation and monitor time skew across all batch servers.
DST transitions cause one-off errors — always test scheduling before and after the change.
Key Takeaway
Debugging starts with autorep -q and autorep -d.
Time drift, DST, and server clock skew are silent causes.
Punchline: verify server time before blaming AutoSys.

The 'everyday' Trap: Why days_of_week and month_days Mutually Exclude Each Other

You think you're being clever. You set days_of_week: "mon,tue,wed,thu,fri" and month_days: "1,15" expecting the job to run only on weekdays that fall on the 1st or 15th. AutoSys laughs. Then it silently ignores the job entirely.

Here's the mechanical truth: days_of_week and month_days form a logical OR when both are present, not AND. AutoSys checks: is today a Monday? Yes → run. Is today the 1st? Yes → run. If neither is true, the job sits dead. You never built a compound gate — you built two independent calendars.

To get the intersection — run only on weekdays that are the 1st or 15th — you need to use a custom calendar or a run_calendar. Don't rely on the fields working together like some SQL WHERE clause. They don't. They're independent dispatch lists. Treat them that way or your job sleeps forever.

IntersectionFail.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
// io.thecodeforge — devops tutorial
// This WILL NOT run on only weekdays that are 1st/15th

job_my_mixed_condition:
  condition: "s(previous_job)"
  date_conditions: "1"
  days_of_week: "mon,tue,wed,thu,fri"  # OR
  month_days: "1,15"                   # OR
  start_times: "08:00"

// Output: job runs every weekday at 08:00 AND on every 1st/15th
// Never fires when you actually need both constraints
Production Trap:
AutoSys does NOT validate conflicting date conditions at job definition time. You will discover this during the post-mortem when someone asks 'Why did the month-end job fire on a Tuesday?'
Key Takeaway
days_of_week and month_days are independent OR gates. Use run_calendar for AND logic.

run_window Bleeding: How a Missed Window Starves Downstream Jobs

A run_window looks clean on paper: "08:00-10:00" means the job must start within that two-hour block. But here's the part they don't put in the docs: if the job misses that window — dependencies not met in time, queue depth, or a previous run overrunning — the job dies for the entire day. There is no fallover to the next window period. It's dead until tomorrow's window.

This creates a starvation cascade. Your downstream jobs sit on condition waiting for the upstream that will never fire. They're not smart enough to skip. They just wait. Forever. Autosys doesn't send an alert for a job that never ran — it only alerts on FAILURE. A job that never started is treated as 'not yet scheduled.'

The fix: use run_window as a health boundary, not a hard gate. Pair it with a max_duration_alarm and a separate monitor that checks 'has job X started today?' If the window closes without a start, page someone. Otherwise you'll find out during the team standup when someone asks 'is the data fresh?' and you realise it's 48 hours stale.

WindowStarvation.ymlYAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// io.thecodeforge — devops tutorial
// Downstream job waits forever if upstream misses window

job_data_pipeline:
  condition: "s(extract_finished)"
  date_conditions: "1"
  days_of_week: "mon,tue,wed,thu,fri"
  run_window: "06:00-10:00"
  start_times: "06:00"

job_data_report:
  condition: "s(data_pipeline)"
  date_conditions: "1"
  days_of_week: "mon,tue,wed,thu,fri"
  start_times: "10:30"

// Output: if data_pipeline doesn't start by 10:00,
// data_report waits forever with status 'ACTIVE' but never runs
Senior Shortcut:
Add a 'watchdog' job that runs at window_end+5min and checks if the windowed job started. Alert if not. This catches silent misses before the post-mortem.
Key Takeaway
A missed run_window kills the job for the entire day. Alert on absence of start, not just failure.
● Production incidentPOST-MORTEMseverity: high

Job Silent No-Run: date_conditions Left at Default

Symptom
The job was defined with start_times: "06:00" and days_of_week: all, but never fired. No alarms, no errors — just silence.
Assumption
The engineer assumed AutoSys would respect start_times automatically, just like cron does.
Root cause
date_conditions was left at its default value of 0, meaning all time-based attributes were ignored. The job existed but had no trigger.
Fix
Added date_conditions: 1 to the job definition using update_job, then forced a re-read with sendevent -e FORCE_START.
Key lesson
  • date_conditions: 1 is not optional — always explicitly set it.
  • When a job doesn't run, autorep -q is your first diagnostic command.
  • Don't assume time scheduling behaves like cron; AutoSys separates conditions from time.
Production debug guideSymptom → Action5 entries
Symptom · 01
Job doesn't run at scheduled time
→
Fix
Check date_conditions status. Use autorep -q jobname | grep -i date_conditions. If 0, update to 1.
Symptom · 02
Job runs but at wrong time
→
Fix
Check timezone attribute and server timezone. Use date command on the AutoSys machine. Add/update timezone attribute if needed.
Symptom · 03
Job runs multiple times unexpectedly
→
Fix
Check start_times for duplicates. Verify if both start_times and start_mins are set — AutoSys may honour both.
Symptom · 04
Job stuck in ACTIVATED state
→
Fix
Check dependency conditions with autorep -d jobname. Time condition may be met but dependency not satisfied.
Symptom · 05
Job not completing within expected window
→
Fix
Verify run_window syntax (space, dash, space). Check term_run_time or max_run_alarm is configured to enforce the window.
★ AutoSys Time Scheduling Quick Debug Cheat SheetQuick commands and fixes for common time scheduling issues.
Job never runs−
Immediate action
Check date_conditions
Commands
autorep -q jobname | grep -i date_conditions
autorep -d jobname
Fix now
update_job: jobname date_conditions: 1
Wrong start time+
Immediate action
Check timezone and server clock
Commands
date
autorep -q jobname | grep -i timezone
Fix now
Add timezone attribute if missing; sync server clock with NTP
Job runs but not on expected days+
Immediate action
Verify days_of_week and calendar
Commands
autorep -q jobname | grep -i days_of_week
autorep -q jobname | grep -i run_calendar
Fix now
Adjust days_of_week or run_calendar definition
Job not respecting run_window+
Immediate action
Check run_window syntax and term_run_time
Commands
autorep -q jobname | grep -i run_window
autorep -q jobname | grep -i term_run_time
Fix now
Ensure run_window has correct format: "hh:mm - hh:mm"
AttributeWhat it controlsExample values
date_conditionsEnable time-based scheduling0 (off), 1 (on)
start_timesClock times to run"02:00", "02:00, 14:00"
days_of_weekWhich daysall, mon-fri, mon,wed,fri
start_minsSub-hourly scheduling"00,15,30,45"
run_windowTime window for execution"22:00 - 06:00"
timezoneTimezone for time interpretationUS/Eastern, Europe/London

Key takeaways

1
date_conditions
1 must be set for start_times and days_of_week to take effect — it defaults to 0
2
start_times specifies clock times; days_of_week specifies which days; both require date_conditions
1
3
run_window bounds when a job should complete; term_run_time hard-terminates after N minutes
4
Use the timezone attribute when jobs must run at local time in a specific region
5
Time conditions can combine with dependency conditions; job starts when both are met
6
Use autorep -q and autorep -d to debug scheduling issues

Common mistakes to avoid

5 patterns
×

Forgetting date_conditions: 1

Symptom
Job doesn't run as scheduled despite start_times and days_of_week being set.
Fix
Add date_conditions: 1 to the job definition.
×

Setting start_times on child jobs inside a BOX

Symptom
Child jobs run at their own schedule instead of waiting for BOX dependencies.
Fix
Remove start_times from child jobs; use condition dependencies instead.
×

Not setting timezone when a job must run at local time across timezone boundaries

Symptom
Job runs at the wrong hour relative to local business requirement.
Fix
Add timezone attribute with appropriate IANA timezone name.
×

Confusing run_window with start_times

Symptom
Job expected to start at a specific time but also expects to finish within a window.
Fix
Understand: start_times defines when the job can start; run_window constrains when it should finish.
×

Assuming run_window terminates the job automatically

Symptom
Job runs beyond the window, consuming resources and possibly blocking the next day's batch.
Fix
Add term_run_time to hard-kill after N minutes, or use max_run_alarm to alert.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR
What does date_conditions do in AutoSys?
Q02SENIOR
If start_times is set but the job never runs, what is the first thing yo...
Q03SENIOR
How do you schedule an AutoSys job to run every 15 minutes?
Q04SENIOR
What is run_window and how does it differ from term_run_time?
Q05SENIOR
How do you schedule an AutoSys job in a specific timezone?
Q01 of 05JUNIOR

What does date_conditions do in AutoSys?

ANSWER
date_conditions is a binary flag that enables time-based scheduling. When set to 1, AutoSys respects start_times, days_of_week, and run_calendar. Default is 0, meaning the job only runs when triggered by conditions or manual intervention.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
Why isn't my AutoSys job running at the scheduled time?
02
How do I schedule an AutoSys job to run every hour?
03
What is run_window in AutoSys?
04
Can an AutoSys job run at both a scheduled time AND when another job finishes?
05
What is the default timezone for AutoSys scheduling?
📖 What to Read Next
→AutoSys Job Dependencies and ConditionsUnderstand how job dependencies interact with time-based scheduling in real pipelines.→AutoSys Job Failure Handling and RestartLearn restart policies and failure handling to complement time scheduling resilience.→AutoSys autorep CommandThe autorep command is your first tool when a scheduled job doesn't run.→AutoSys date_conditions and run_windowClarifies the exact difference between these two often-confused attributes.→Introduction to AutoSysKnow which job type suits your time-based scenario, especially BOX for orchestrating multiple timed jobs.
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.

N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Everything here is grounded in real deployments.

Follow
✓ Verified
production tested
May 24, 2026
last updated
1,554
articles · all by Naren
🔥

That's AutoSys. Mark it forged?

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

←
Previous
JIL One-Time Job Overrides
13 / 30 · AutoSys
Next
AutoSys Job Dependencies and Conditions
→