DevOps Beginner

AutoSys Job Scheduling — Time Conditions, start_times, and days_of_week

📅 March 19, 2026 ⏱ 3 min read 🎯 Beginner

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

📍 Part of: AutoSys → Topic 13 of 30

Learn how AutoSys job scheduling works: date_conditions, start_times, days_of_week, run_window, and timezone.

🧑‍💻 Beginner-friendly — no prior DevOps experience needed

In this tutorial, you'll learn

Learn how AutoSys job scheduling works: date_conditions, start_times, days_of_week, run_window, and timezone.

date_conditions: 1 must be set for start_times and days_of_week to take effect — it defaults to 0
start_times specifies clock times; days_of_week specifies which days; both require date_conditions: 1
run_window bounds when a job should complete; term_run_time hard-terminates after N minutes

thecodeforge.io

Time-Based Scheduling Flow

Autosys Job Scheduling Time Conditions

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

⚡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

🚨 START HERE

AutoSys Time Scheduling Quick Debug Cheat Sheet

Quick commands and fixes for common time scheduling issues.

🟡

Job never runs

Immediate ActionCheck date_conditions

Commands

autorep -q jobname | grep -i date_conditions

autorep -d jobname

Fix Nowupdate_job: jobname date_conditions: 1

🟡

Wrong start time

Immediate ActionCheck timezone and server clock

Commands

date

autorep -q jobname | grep -i timezone

Fix NowAdd timezone attribute if missing; sync server clock with NTP

🟡

Job runs but not on expected days

Immediate ActionVerify days_of_week and calendar

Commands

autorep -q jobname | grep -i days_of_week

autorep -q jobname | grep -i run_calendar

Fix NowAdjust days_of_week or run_calendar definition

🟡

Job not respecting run_window

Immediate ActionCheck run_window syntax and term_run_time

Commands

autorep -q jobname | grep -i run_window

autorep -q jobname | grep -i term_run_time

Fix NowEnsure run_window has correct format: "hh:mm - hh:mm"

Production Incident

Job Silent No-Run: date_conditions Left at Default

A critical batch job didn't run at 06:00, missing the morning window and triggering a cascading pipeline failure.

SymptomThe job was defined with start_times: "06:00" and days_of_week: all, but never fired. No alarms, no errors — just silence.

AssumptionThe engineer assumed AutoSys would respect start_times automatically, just like cron does.

Root causedate_conditions was left at its default value of 0, meaning all time-based attributes were ignored. The job existed but had no trigger.

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

Symptom → Action

Job doesn't run at scheduled time→Check date_conditions status. Use autorep -q jobname | grep -i date_conditions. If 0, update to 1.

Job runs but at wrong time→Check timezone attribute and server timezone. Use date command on the AutoSys machine. Add/update timezone attribute if needed.

Job runs multiple times unexpectedly→Check start_times for duplicates. Verify if both start_times and start_mins are set — AutoSys may honour both.

Job stuck in ACTIVATED state→Check dependency conditions with autorep -d jobname. Time condition may be met but dependency not satisfied.

Job not completing within expected window→Verify run_window syntax (space, dash, space). Check term_run_time or max_run_alarm is configured to enforce the window.

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

12345678910111213141516171819

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

12345678910111213141516171819

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

12345678910

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

123456789

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

123456789

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

1234567891011

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

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

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

⚠ Common Mistakes to Avoid

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

QWhat does date_conditions do in AutoSys?JuniorReveal
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.
QIf start_times is set but the job never runs, what is the first thing you check?Mid-levelReveal
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.
QHow do you schedule an AutoSys job to run every 15 minutes?Mid-levelReveal
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.
QWhat is run_window and how does it differ from term_run_time?SeniorReveal
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.
QHow do you schedule an AutoSys job in a specific timezone?SeniorReveal
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.

Frequently Asked Questions

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.

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.

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.

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.

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.

🔥

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