No built-in delay: a condition like s(MAIN_JOB) fires the moment MAIN_JOB succeeds.
Exact delay: add a CMD job running sleep 300 with condition s(MAIN_JOB), and make the dependent job depend on that.
Approximate delay: give the dependent job date_conditions: 1 with start_mins: 00,05,10,…; it starts at the next listed minute after the condition is true (between 0 and 5 minutes later).
Don't hide sleep 300 inside a script: the delay becomes invisible in the schedule.
Ask why you need a delay: if you're waiting for a file or data to be ready, wait for that instead (file watcher or a readiness check).
✦ Definition~90s read
What is AutoSys?
AutoSys starts a dependent job as soon as its condition is true. There's no attribute to wait N minutes after the upstream job finishes, so a delay is built from a small job in between, or from start times combined with the condition.
★
AutoSys is like a relay runner who grabs the baton the instant it's offered.
Plain-English First
AutoSys is like a relay runner who grabs the baton the instant it's offered. If you want them to wait five minutes, you put a second runner in between whose only job is to stand still for five minutes, then pass it on.
"Run job B five minutes after job A finishes" sounds like it should be one line of JIL. It isn't: AutoSys conditions have no delay. This guide shows the two patterns teams use, the JIL for each, and the case where a delay is hiding a real readiness problem.
Why There's No Delay Attribute
A condition such as s(MAIN_JOB) is evaluated by the scheduler as events arrive. The moment MAIN_JOB's SUCCESS event is processed, the condition is true and the dependent job starts, as long as any date conditions also allow it. There is no attribute to say "and then wait five minutes", so the delay has to be built.
Conditions fire immediately; a delay has to be modelled.
Pattern 1: A Sleep Job In Between (Exact Delay)
Add a small CMD job whose only command is sleep, depending on the main job. The dependent job then depends on the sleep job. The wait shows up in the schedule, in autorep and in your monitoring, so everyone can see why the dependent job hasn't started.
A name like FIN_EXPORT_WAIT5 tells an operator at 3 a.m. exactly what the job is waiting for and how long.
🎯 Key Takeaway
A visible WAIT job gives an exact, auditable delay.
Pattern 2: start_mins With the Condition (Approximate Delay)
If the delay doesn't need to be exact, give the dependent job both a condition and start times. A job with date_conditions: 1 starts only when its condition is true and a listed start time arrives. With start_mins every five minutes, it starts at the next five-minute mark after the main job succeeds: somewhere between 0 and 5 minutes later. No extra job, but less precise.
start_mins.jilTEXT
1
2
3
4
5
update_job: RPT_DAILY
condition: s(FIN_EXPORT)
date_conditions: 1
days_of_week: all
start_mins: 00,05,10,15,20,25,30,35,40,45,50,55
⚠ Check it runs once
With start_mins every five minutes the job could start again at the next mark if the condition is still true. Test this on your version, and make sure the job runs only once per cycle, for example by putting both jobs in a box.
🎯 Key Takeaway
Condition + start_mins = start at the next listed minute after success.
When a Delay Is the Wrong Fix
Most "wait five minutes" requests are really "wait until the file has arrived" or "wait until the load has committed". A delay only guesses at that. If the main job hands over a file, use a file watcher job on it; if it's data in a database, have a small job check that the data is there and fail if it isn't. Then the dependent job starts as soon as things are actually ready, and never too early.
file_watch.jilTEXT
1
2
3
4
5
6
7
8
9
10
insert_job: FIN_EXPORT_READY
job_type: FW
watch_file: /shared/fin/export_daily.csv
watch_interval: 60 /* size must be steady for60 s */
machine: rptbatch01
owner: rptbatch
condition: s(FIN_EXPORT)
update_job: RPT_DAILY
condition: s(FIN_EXPORT_READY)
🎯 Key Takeaway
Wait for readiness, not the clock, whenever you can.
● Production incidentPOST-MORTEMseverity: high
Five Minutes Wasn't Always Enough
Symptom
RPT_DAILY intermittently produced reports with missing rows, always on nights with high volume.
Assumption
The team assumed 5 minutes was always enough time for the file to replicate after FIN_EXPORT succeeded.
Root cause
Replication of the export file took 2 minutes on quiet nights and up to 9 minutes on busy ones. The fixed delay was a guess, and on busy nights the report read a partially copied file.
Fix
Replaced the 5-minute sleep job with a file watcher job on the replicated file (watching until its size stopped changing), and made the report depend on the watcher's success.
Key lesson
A fixed delay is a guess about how long something takes.
When you're waiting for a file or data, wait for that, not for the clock.
Keep any delay visible in the schedule as its own job.
Production debug guideMake the wait visible, then make it correct4 entries
Symptom · 01
Dependent job starts the instant the main job ends
→
Fix
That's normal: conditions have no delay. Add a sleep job in between or use start_mins.
Symptom · 02
Dependent job waits up to an hour
→
Fix
start_times or start_mins is too sparse; the job starts at the next listed time after the condition is true.
Symptom · 03
Dependent job never starts with start_mins
→
Fix
Check date_conditions: 1 is set; without it start_mins is ignored.
Symptom · 04
Delay sometimes too short
→
Fix
You're waiting for something real (file, replication, a DB load). Replace the delay with a file watcher or readiness check.
⚙ Quick Reference
4 commands from this guide
File
Command / Code
Purpose
today.jil
insert_job: RPT_DAILY
Why There's No Delay Attribute
sleep_job.jil
insert_job: FIN_EXPORT_WAIT5
Pattern 1
start_mins.jil
update_job: RPT_DAILY
Pattern 2
file_watch.jil
insert_job: FIN_EXPORT_READY
When a Delay Is the Wrong Fix
Key takeaways
1
AutoSys conditions start the dependent job immediately.
2
For an exact delay, add a visible sleep job in between.
3
For an approximate one, combine the condition with start_mins and date_conditions
1.
4
Don't hide sleeps inside scripts.
5
If you're waiting for a file or data, wait for that instead.
Common mistakes to avoid
3 patterns
×
Putting sleep 300 at the top of the dependent job's script
Symptom
The job shows RUNNING while it isn't doing anything, and the delay is invisible in the schedule.
Fix
Use a separate, clearly named WAIT job.
×
start_mins without date_conditions: 1
Symptom
The start times are ignored and the job starts immediately on the condition.
Fix
Set date_conditions: 1 with the start_mins.
×
Using a delay to wait for a file
Symptom
Works on quiet days, fails on busy ones.
Fix
Use a file watcher job or a readiness check.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
How do you start an AutoSys job five minutes after another job succeeds?
Q02SENIOR
Why might a fixed delay between two jobs be a bad design?
Q01 of 02SENIOR
How do you start an AutoSys job five minutes after another job succeeds?
ANSWER
There's no delay attribute. Insert a CMD job that runs sleep 300 with condition s(MAIN), and make the dependent job depend on it; or combine the condition with start_mins for an approximate delay.
Q02 of 02SENIOR
Why might a fixed delay between two jobs be a bad design?
ANSWER
It guesses how long something takes. If the real need is a file or data being ready, wait for that with a file watcher or a check job, so it is never too early or needlessly late.
01
How do you start an AutoSys job five minutes after another job succeeds?
SENIOR
02
Why might a fixed delay between two jobs be a bad design?
SENIOR
FAQ · 2 QUESTIONS
Frequently Asked Questions
01
How do I run a dependent job 5 minutes after the main job in AutoSys?
Create a CMD job that runs sleep 300 with condition s(MAIN_JOB), and give the dependent job condition s(THAT_SLEEP_JOB).
Was this helpful?
02
Does AutoSys have a delay attribute for conditions?
No. Conditions fire as soon as they're true; delays are built with an extra job or with start times.