s(JOB) has no age limit: an old success keeps satisfying it.
s(JOB, 06.00) = success within the last 6 hours (format hhhh.mm).
s(JOB, 0) = JOB completed since this (dependent) job last ran.
Use 0 when each upstream run should trigger exactly one downstream run.
Use hh.mm when you mean 'today's run'. Keep it shorter than the gap between upstream runs.
Works for s(), f(), d() and t().
On the daylight-saving fall-back night, a one-hour lookback can miss; use two.
✦ Definition~90s read
What is AutoSys Lookback Conditions?
A lookback is an optional time limit on an AutoSys condition. s(JOB) is satisfied while JOB's last run ended in success, however long ago. s(JOB, hh.mm) is satisfied only if that success happened within the last hh hours and mm minutes. s(JOB, 0) is satisfied only if JOB completed after the dependent job's own last run.
★
s(JOB) is a green light that stays green until someone changes it.
Plain-English First
s(JOB) is a green light that stays green until someone changes it. A lookback puts a timer on the light: 01.00 means it goes back to red after an hour. A lookback of 0 means it's green only for news you haven't acted on yet.
An hourly loader with condition: s(FEED) loaded the same file four times, because one success from 01:02 kept the condition true all night. A lookback limits how old that success can be.
Why s(JOB) Repeats
A condition reads the upstream job's current status. After a success, the status stays SUCCESS until that job runs again. A dependent job with its own start times passes the condition every time it starts.
wrong.jilJIL
1
2
3
4
insert_job: LOAD_TRADES job_type: CMD
date_conditions: 1
start_mins: 05
condition: s(FEED_TRADES) # true all night after one success
🎯 Key Takeaway
s() checks the last run, not a new run.
Lookback in Hours: s(JOB, hh.mm)
Add a second argument in hours and minutes. The success must be within that window, measured back from when the condition is evaluated.
hours.jilJIL
1
2
3
condition: s(FEED_TRADES, 01.00) # success in the last hour
condition: s(LOAD_BOX, 06.00) # today's run of a daily box
condition: s(EOD, 00.30) # last 30 minutes
🎯 Key Takeaway
hh.mm = maximum age of the success.
Lookback 0: Since My Last Run
With 0, the upstream job must have completed after the dependent job's last run. Each upstream success can start the dependent job once.
0 for one-to-one triggering; hh.mm when you mean today's run. Keep an hh.mm window shorter than the gap between upstream runs.
🎯 Key Takeaway
0 = new since I last ran.
Other Statuses and Daylight Saving
Lookbacks work the same on f(), d() and t(). When clocks go back, an hour repeats, and a one-hour window can miss the run; use 02.00 that night or permanently.
examples.txtTEXT
1
2
3
f(JOB, 02.00) failed in the last 2 hours
d(JOB, 0) done since I last ran
t(JOB, 01.30) terminated in the last 90 minutes
🎯 Key Takeaway
Same rule for every status.
● Production incidentPOST-MORTEMseverity: high
The File Loaded Four Times
Symptom
Duplicate key errors on trades_1109.csv and four load runs for one feed.
Assumption
The team expected s(FEED_TRADES) to mean 'a new feed arrived'.
Root cause
s(FEED_TRADES) means 'the last FEED_TRADES run succeeded'. It stayed true until the feed ran again, so every hourly start passed.
Fix
Changed the condition to s(FEED_TRADES, 0), so the loader only starts on a feed run newer than its own last run.
Key lesson
s() has no age limit.
Use lookback 0 for one-to-one triggering.
Use hh.mm for 'today's run'.
Production debug guideWhy did it run, or not?3 entries
Symptom · 01
Dependent job runs again on an old success
→
Fix
Add a lookback: s(JOB, 0) or s(JOB, hh.mm).
Symptom · 02
Dependent job waits although the upstream succeeded
→
Fix
The success is older than the lookback window, or older than the dependent job's last run with 0. Compare autorep -J UPSTREAM last end time.
Symptom · 03
Skipped once a year in autumn
→
Fix
Daylight saving fall-back repeats an hour; widen a one-hour lookback to two.
⚙ Quick Reference
4 commands from this guide
File
Command / Code
Purpose
wrong.jil
insert_job: LOAD_TRADES job_type: CMD
Why s(JOB) Repeats
hours.jil
condition: s(FEED_TRADES, 01.00) # success in the last hour
Lookback in Hours
zero.jil
update_job: LOAD_TRADES
Lookback 0
examples.txt
f(JOB, 02.00) failed in the last 2 hours
Other Statuses and Daylight Saving
Key takeaways
1
s(JOB) never expires on its own.
2
s(JOB, hh.mm) limits the age of the success.
3
s(JOB, 0) = since the dependent job's last run.
4
Works for s, f, d, t.
5
Watch DST with one-hour windows.
Common mistakes to avoid
3 patterns
×
s(JOB) on an hourly dependent
Symptom
Same input processed every hour.
Fix
s(JOB, 0).
×
Lookback longer than the gap between upstream runs
Symptom
Yesterday's run still counts.
Fix
Shorter window, or 0.
×
One-hour lookback across DST
Symptom
One run skipped on the fall-back night.
Fix
Use 02.00.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What does s(JOB, 0) mean in AutoSys?
Q02SENIOR
Why would a dependent job keep running on an old success?
Q01 of 02SENIOR
What does s(JOB, 0) mean in AutoSys?
ANSWER
JOB must have completed successfully since the dependent job last ran.
Q02 of 02SENIOR
Why would a dependent job keep running on an old success?
ANSWER
s() without a lookback stays true until the upstream job runs again.
01
What does s(JOB, 0) mean in AutoSys?
SENIOR
02
Why would a dependent job keep running on an old success?
SENIOR
FAQ · 3 QUESTIONS
Frequently Asked Questions
01
What is a lookback condition in AutoSys?
A time limit on a condition: s(JOB, hh.mm) requires the success within that window; s(JOB, 0) requires it since the dependent job last ran.
Was this helpful?
02
What is the lookback format?
hhhh.mm, hours then minutes, e.g. 06.00 for six hours or 00.30 for thirty minutes.
Was this helpful?
03
Why is my job not starting even though the upstream succeeded?
The success is older than the lookback window, or older than the job's own last run when the lookback is 0.