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
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.
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.
thecodeforge.io
Time-Based Scheduling Flow
Autosys Job Scheduling Time Conditions
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 2AM, 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 15minutes (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.
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 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
# Checkfor 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.
● 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"
Attribute
What it controls
Example values
date_conditions
Enable time-based scheduling
0 (off), 1 (on)
start_times
Clock times to run
"02:00", "02:00, 14:00"
days_of_week
Which days
all, mon-fri, mon,wed,fri
start_mins
Sub-hourly scheduling
"00,15,30,45"
run_window
Time window for execution
"22:00 - 06:00"
timezone
Timezone for time interpretation
US/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.
Q02 of 05SENIOR
If start_times is set but the job never runs, what is the first thing you check?
ANSWER
Check date_conditions: it must be set to 1. Then verify days_of_week includes today, and that no blocking conditions exist. Use autorep -q to dump the job definition.
Q03 of 05SENIOR
How do you schedule an AutoSys job to run every 15 minutes?
ANSWER
Set date_conditions: 1, days_of_week: all, and start_mins: "00,15,30,45". start_mins allows sub-hourly scheduling. Alternatively, use start_times with 96 entries but start_mins is cleaner and easier to maintain.
Q04 of 05SENIOR
What is run_window and how does it differ from term_run_time?
ANSWER
run_window defines a time range within which the job should complete. AutoSys generates an alarm if the job is still running at window close. term_run_time hard-terminates the job after N minutes regardless. run_window is a soft bound; term_run_time is a hard kill.
Q05 of 05SENIOR
How do you schedule an AutoSys job in a specific timezone?
ANSWER
Add the timezone attribute with the IANA timezone name (e.g., timezone: US/Eastern). Without it, AutoSys uses the server's local timezone. Always set timezone explicitly for multi-region environments.
01
What does date_conditions do in AutoSys?
JUNIOR
02
If start_times is set but the job never runs, what is the first thing you check?
SENIOR
03
How do you schedule an AutoSys job to run every 15 minutes?
SENIOR
04
What is run_window and how does it differ from term_run_time?
SENIOR
05
How do you schedule an AutoSys job in a specific timezone?
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
Why isn't my AutoSys job running at the scheduled time?
The most common reason is date_conditions is not set to 1. Without date_conditions: 1, start_times and days_of_week are ignored. Also check that days_of_week includes today and that no conditions are blocking the job. Use autorep -q to verify the definition.
Was this helpful?
02
How do I schedule an AutoSys job to run every hour?
Set date_conditions: 1, days_of_week: all, and use start_mins or multiple start_times. For hourly: use a combination of start_times listing every hour, or use a BOX that repeats daily with internal hourly scheduling.
Was this helpful?
03
What is run_window in AutoSys?
run_window defines the time range within which a job should run and complete. If the job starts within the window but the window closes before it finishes, AutoSys can generate an alarm or terminate the job depending on configuration — specifically the term_run_time attribute.
Was this helpful?
04
Can an AutoSys job run at both a scheduled time AND when another job finishes?
Yes. You can combine date_conditions: 1 with a condition attribute. The job starts when BOTH its time conditions are met AND its dependency condition is true. This is a common pattern for batch workflows.
Was this helpful?
05
What is the default timezone for AutoSys scheduling?
AutoSys uses the server's local timezone by default. Use the timezone attribute in the job definition to specify a different timezone explicitly — essential for multinational environments.