Intermediate 3 min · March 19, 2026

AutoSys success() — INACTIVE Jobs Block Chains Silently

success(job_A) stays false indefinitely when job_A is INACTIVE, not failed.

Naren · Founder

Plain-English first. Then code. Then the interview question.

⚡Quick Answer

AutoSys conditions define when a job can start based on other jobs' statuses
Four functions: success(), failure(), done(), notrunning()
Combine with AND / OR and parentheses for complex rules
Conditions evaluate after the referenced job finishes (or stops running for notrunning)
Common failure: using success() for cleanup jobs — use done() instead
In production, complex conditions with many AND/OR masks timing issues — test with autorep first

Dependency management is AutoSys's superpower — the thing that justifies its cost over cron. The condition attribute lets you express exactly what must be true before a job can start. You can chain hundreds of jobs with precise dependency rules, and AutoSys handles the orchestration automatically.

This article covers all condition types, how to combine them, and the gotchas that cause dependency chains to break in production.

The four condition functions

AutoSys provides four functions for expressing job conditions:

success(job): Triggers when the referenced job completes with exit code 0
failure(job): Triggers when the referenced job completes with non-zero exit code
done(job): Triggers when the referenced job completes, regardless of exit code
notrunning(job): Triggers when the referenced job is not currently in RUNNING state

Each function takes the name of another job (or box) as argument. The condition is evaluated when the referenced job changes state. For success(), failure(), and done() the state change is completion/termination. For notrunning() it's any transition out of RUNNING, including job start (from not-running to running also triggers, but that's not typical usage).

thecodeforge.io

Job Dependency Chain

Autosys Job Dependencies Conditions

Cross-box dependencies

Conditions can reference jobs in other boxes or standalone jobs. This lets you build workflows that span multiple boxes.

When a condition references a job outside the current box, AutoSys uses global job name resolution. The referenced job must have a unique name across the entire AutoSys instance — if duplicates exist, the condition may resolve to the wrong job.

You cannot condition on a box name to wait for all children of that box. Instead, condition on the last child job of that box, or use done(box_name) which completes only when all children of that box have finished.

The done() condition and why it matters

done() is often overlooked but very useful. It lets a job run after another job completes regardless of whether that job succeeded or failed. This is perfect for cleanup or notification jobs that should always run.

Use cases

Cleanup temp files after a job completes
Send status email with success/failure info
Update a monitoring system with job execution results

Because done() triggers after any termination — including kill or timeout — it ensures your post-processing runs reliably.

notrunning(): preventing concurrent execution

The notrunning() condition triggers when the referenced job is not in RUNNING state. This is useful for throttling or serialising jobs that share a resource.

Important caveat: notrunning() evaluates true if the referenced job has never run (INACTIVE status). That means if you write condition: notrunning(app_job) and app_job hasn't been scheduled yet, the condition is immediately true — the dependent job will start right away, likely not what you intended.

To prevent concurrent runs of the same job, use condition: notrunning(app_job) where app_job is the same job. AutoSys supports self-referencing conditions for this purpose. When used on the same job, the condition is met only after the previous instance finishes.

Complex conditions with AND, OR, and parentheses

You can build complex dependency logic by combining conditions with AND and OR operators, and using parentheses to control evaluation order. AutoSys evaluates conditions from left to right, respecting parentheses. There's no NOT operator.

Example: You need a job to run if either Job A and Job B both succeeded, OR Job C succeeded. The condition would be:

condition: (success(job_a) AND success(job_b)) OR success(job_c)

Without parentheses, AND has higher precedence than OR, so: condition: success(job_a) AND success(job_b) OR success(job_c) is equivalent to: condition: (success(job_a) AND success(job_b)) OR success(job_c)

However, it's safer to always use explicit parentheses for readability and to avoid future misinterpretation.

Complex conditions are powerful but can lead to hard-to-debug behaviours. If you have many conditions, consider breaking the logic into intermediate box jobs to simplify each condition.

Condition Function Comparison

Condition	Triggers when...	Common use case
success(job)	Job completed with exit code 0	Normal sequential dependency
failure(job)	Job completed with non-zero exit code	Error handling / failover job
done(job)	Job completed (either success or failure)	Cleanup / notification jobs
notrunning(job)	Job is not currently RUNNING	Preventing concurrent execution

Key Takeaways

AutoSys provides four condition types: success(), failure(), done(), and notrunning()
done() is the right choice for cleanup or notification jobs that must run regardless of the upstream job's outcome
Conditions can reference jobs in other boxes or boxes themselves
AND/OR logic lets you build complex dependency rules — test them carefully before deploying to production
Circular dependencies are not detected at definition time; manually review chains for loops
notrunning() is for concurrency control, not sequential dependency — it evaluates true if the referenced job never ran

Common Mistakes to Avoid

Using success() instead of done() for cleanup jobs
Symptom: Cleanup job never runs when the main job fails. Temp files accumulate, disk fills up, future jobs fail.
Fix: Change condition to: condition: done(main_job). Cleanup now runs regardless of success or failure.
Not accounting for jobs in INACTIVE state
Symptom: A dependent job with condition: success(job_A) never runs because job_A has never executed (INACTIVE). Pipeline deadlocks silently.
Fix: Ensure job_A is scheduled or forced to run. Alternatively, use done() if the dependency is not strict. Use autorep -q job_A to verify status before batch.
Creating circular dependencies
Symptom: Job A depends on B, Job B depends on A. Both stay PENDING forever. No error at definition time.
Fix: Manually review dependency chains. Autosys does not detect cycles. Use a tool or script to trace dependency graphs. Break the cycle by redesigning workflow.
Misunderstanding OR conditions leading to early triggering
Symptom: Job starts when one of two upstream jobs succeeds, even though both were expected before starting.
Fix: Use AND instead of OR if all dependencies are required. If OR is intended but the trigger happens too early, consider using a box to group the upstream jobs and condition on the box.
Assuming notrunning() waits for a job to run
Symptom: Job with condition: notrunning(resource_job) starts immediately because resource_job never ran and is INACTIVE.
Fix: Use success() or done() for sequential dependencies. Only use notrunning() when you specifically want to check runtime state.

Interview Questions on This Topic

QWhat is the difference between success() and done() conditions in AutoSys?JuniorReveal
success() triggers when the referenced job completes with exit code 0 (success). done() triggers when the reference job completes regardless of exit code. So done() runs even if the job failed, while success() only runs on success. Use success() for normal chaining and done() for cleanup or notification jobs that must always execute.
QWhat does the condition failure() do?JuniorReveal
failure(job) triggers when the referenced job completes with a non-zero exit code (failure). It is used for error-handling jobs, such as sending an alert or triggering a recovery process. It does not trigger if the job never ran or was killed.
QCan an AutoSys job condition reference jobs in a different box?Mid-levelReveal
Yes. Conditions can reference any job in the AutoSys instance by its unique name, regardless of box membership. To wait for an entire box, condition on the box job itself, but note that done(box_name) waits for all children of the box to finish. Alternatively, condition on the last job inside the box.
QWhat happens if you have a circular dependency in AutoSys conditions?SeniorReveal
AutoSys does not detect circular dependencies at job definition or scheduling time. The jobs will remain in PENDING state indefinitely, waiting for each other. This causes a silent deadlock. You must manually identify and fix the cycle. Use autorep -q <job> to see conditions and trace dependencies.
QWhat condition would you use for a cleanup job that must run whether or not the main job succeeded?JuniorReveal
Use done(main_job). This ensures the cleanup job runs after the main job completes, regardless of its exit code. If the cleanup should only run on success or failure, use success() or failure() respectively.
QHow does the notrunning() condition behave if the referenced job has never run?SeniorReveal
notrunning() evaluates true when the referenced job is not in RUNNING state. If the job has never run (INACTIVE), it is not running, so notrunning() returns true immediately. This can cause unexpected early triggering. To avoid this, combine notrunning() with a start_times or ensure the referenced job is scheduled.

Frequently Asked Questions

What conditions can I use in AutoSys?

AutoSys provides four condition functions: success(job) — job completed successfully; failure(job) — job failed; done(job) — job completed regardless of outcome; notrunning(job) — job is not currently running. You can combine these with AND and OR operators.

What is the done() condition in AutoSys?

done() triggers when a job has completed, whether it succeeded or failed. It's commonly used for cleanup jobs, status notification jobs, or any job that should always run after an upstream job finishes, regardless of outcome.

Can AutoSys job conditions span multiple boxes?

Yes. The condition attribute can reference any job in the AutoSys instance, regardless of which box it belongs to. The referenced job name must be unique across the instance.

What happens if I create a circular dependency in AutoSys?

AutoSys won't detect circular dependencies at job definition time. The jobs will deadlock — Job A waits for B, Job B waits for A, and neither ever starts. You need to carefully review dependency chains to prevent this.

How do I make a job run after any one of several jobs succeeds?

Use OR in your condition: condition: success(job_a) OR success(job_b). The job starts as soon as either condition becomes true.

What is the difference between notrunning() and success()?

notrunning() checks if a job is currently not running (state is not RUNNING). It evaluates true if the job never ran, finished, or was killed. success() only evaluates true after the job has completed with exit code 0. Use success() for sequential chaining, notrunning() for serialization.

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.

🔥

That's AutoSys. Mark it forged?

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