AutoSys success() — INACTIVE Jobs Block Chains Silently

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.

Why AutoSys Job Dependencies Are Not Just Conditions

AutoSys job dependencies define the execution order of jobs in a batch processing pipeline. The core mechanic is the condition string — a boolean expression referencing upstream job statuses (success(), failure(), terminated(), etc.). When all conditions evaluate to true, the downstream job becomes eligible to start. This is the fundamental scheduling primitive in AutoSys.

A critical property: conditions are evaluated against the most recent run of each referenced job. If an upstream job has never run, its status is INACTIVE, and success() evaluates to false — the downstream job blocks indefinitely. This is not a timeout; it's a silent deadlock. The scheduler does not emit an alert; the job simply never starts.

Use dependencies when you need strict sequential processing — ETL pipelines, data validation chains, or any workflow where job B must only run after job A completes successfully. In practice, this means every upstream job must have at least one completed run in the job's history before the dependency can ever trigger. Teams new to AutoSys often miss this and wonder why their pipeline never kicks off.

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

/* success(job) — run after job_a completes successfully */
condition: success(job_a)

/* failure(job) — run after job_a fails (error handling job) */
condition: failure(job_a)

/* done(job) — run after job_a is done, regardless of success or failure */
condition: done(job_a)

/* notrunning(job) — run when job_a is NOT currently running */
condition: notrunning(job_a)

/* Combining conditions with AND */
condition: success(job_a) AND success(job_b)

/* Combining with OR */
condition: success(job_a) OR success(job_b)

/* Complex condition */
condition: success(job_a) AND (success(job_b) OR success(job_c))

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.

/* Job in reporting_box waits for a job in etl_box */
insert_job: generate_daily_report
job_type: CMD
box_name: reporting_box
command: /scripts/daily_report.sh
machine: report-server
owner: batch
condition: success(etl_load_job)   /* etl_load_job is in etl_box */

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.

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

/* Cleanup job: runs whether or not main job succeeded */
insert_job: cleanup_temp_files
job_type: CMD
command: /scripts/cleanup.sh
machine: server01
owner: batch
condition: done(main_etl_job)   /* runs regardless of main_etl_job outcome */

/* Notification job: always sends status email */
insert_job: send_batch_status_email
job_type: CMD
command: "/scripts/notify.sh --job main_etl_job"
machine: server01
owner: batch
condition: done(main_etl_job)

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.

/* Report generator: only one instance at a time */
insert_job: daily_report
job_type: CMD
command: /scripts/report.sh
machine: server01
owner: batch
condition: notrunning(daily_report)   /* self-reference prevents overlap */

/* Resource-dependent job: wait until resource job finishes */
insert_job: process_batch
job_type: CMD
command: /scripts/process.sh
machine: server02
owner: batch
condition: notrunning(resource_cleanup)   /* ensures cleanup is not running */

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.

/* Real-world example: Run final aggregation if (ETL success AND validation success) OR manual override flag */
insert_job: final_aggregation
job_type: CMD
box_name: reporting_box
command: /scripts/aggregate.sh
machine: batch-server
owner: batch
condition: (success(run_etl) AND success(validate_data)) OR success(manual_override)

/* Use intermediate box to simplify */
insert_job: etl_and_validation_box
job_type: BOX

insert_job: run_etl
job_type: CMD
box_name: etl_and_validation_box
command: /scripts/etl.sh

insert_job: validate_data
job_type: CMD
box_name: etl_and_validation_box
command: /scripts/validate.sh
condition: success(run_etl)

/* Now final job condition becomes simpler */
insert_job: final_aggregation
job_type: CMD
command: /scripts/aggregate.sh
condition: success(etl_and_validation_box) OR success(manual_override)

Why Your Dependency Tree Will Break (and How to Fail Fast)

You've wired ten jobs in a cascade with AND conditions, expecting a nice serial execution. Then nothing runs. You check the database — the predecessor ran fine three hours ago.

Here's what happened: AutoSys checks conditions at the moment the job is scheduled to start. If a predecessor finished at 10:00 and your dependent job starts at 12:00, a simple done(jobA) condition should work. But if the predecessor ran a different box or was manually restarted, its exit status may have been overwritten or never recorded.

The fix: always pin your dependency on a specific run number or instance. Use done(jobA.1) to refer to the first execution of that day. Even better — combine with exitcode() to catch failed runs before your job even considers starting.

Fail fast means your job alerts you within its first minute of the window, not after you've waited an hour. Store predecessor exit codes in a global variable and check them in a pre-processing job. That single step has saved my team from three post-mortems this year.

// io.thecodeforge — devops tutorial

// Fail fast by pinning to run instance + exit code
insert_job: daily_payment_validation
job_type: c
command: /opt/billing/check_payments.sh
machine: batch-prod-01
days_of_week: mo,tu,we,th,fr
start_mins: 0,15,30,45
condition: done(daily_data_export.1) AND exitcode(daily_data_export.1) = 0

The sendevent Trap: When Your Manual Override Destroys Your Pipeline

Something is stuck. You run sendevent -E FORCE_STARTJOB job_payroll_merge because the condition hasn't been met and payroll is due. It works. The job runs. You go home.

Next morning: seventeen downstream jobs failed. The FORCE_STARTJOB event set the job's status to SUCCESS but did not update the condition history. Downstream jobs checked for done(job_payroll_merge.1) — AutoSys had no record of that run instance because it was forced, not naturally triggered.

Use sendevent -E CHANGE_STATUS -s SUCCESS instead. This updates the job's status in the database and records the completion time, so conditions evaluate correctly. But even that is dangerous — it bypasses any exit code logic.

Better approach: write a small wrapper script that checks if the condition would have been met naturally, then only then forces the start. Log every forced start to a dedicated file with a timestamp and operator ID. You want a paper trail for every time you override the system.

I've seen this take down a quarterly close pipeline because someone forced a job that skipped a data validation step. The data was corrupt for three weeks.

// io.thecodeforge — devops tutorial

// Wrapper that logs forced starts before executing
#!/bin/bash
JOB_NAME="$1"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
OPERATOR=$(whoami)
echo "${TIMESTAMP} - ${OPERATOR} - FORCE_STARTJOB ${JOB_NAME}" >> /var/log/autosys/force_starts.log

// Example forced start with logging
sendevent -E CHANGE_STATUS -s SUCCESS -j job_payroll_merge "forced by ${OPERATOR} at ${TIMESTAMP}"

Condition Settings for Various Outcomes

AutoSys conditions are not limited to job success or failure. You can trigger jobs based on termination signals, exit codes, or even the absence of a job run. The term() condition catches jobs killed by sendevent -e FORCE_START or OS signals like SIGKILL. This prevents your pipeline from hanging indefinitely when a job crashes abnormally. For exit-code precision, use exitcode(job_name, N) to trigger on specific return values. Combined with failure conditions, you can route jobs to remediation scripts only when critical errors occur. A common mistake is assuming done(job_name) covers all outcomes—it does not. If your downstream job must run only when the upstream exits with code 42, you must write exitcode(JOB_A, 42) rather than a generic success condition. Failed jobs (exit code != 0) require failure(JOB_A). This granularity saves debugging time and prevents cascading failures in multi-step workflows.

// io.thecodeforge — devops tutorial
// Trigger on specific exit codes or termination
job_type: c
command: "/opt/scripts/validate.sh"
condition: "exitcode(PARSE_LOG, 42) OR term(FETCH_DATA)"
alarm_if_fail: 1
max_run_alarm: 1

Template Parameters in Conditions

AutoSys job definitions often use templates with variables like %%JOB_NAME or %%BOX_RUN_ID. Conditions in template-based jobs must reference these parameters carefully because the condition string is parsed before variable substitution. If you write condition: done(%%PARENT_JOB), AutoSys will interpret the literal text '%%PARENT_JOB' at parse time. Instead, define conditions using static names and apply the template to concrete instances after substitution. For parameterized dependencies across multiple environments, use global_vars within the condition, referencing variables set by upstream jobs. Example: condition: status(%%DB_HOST_PING, SUCCESS) fails because '%%DB_HOST_PING' is unknown. The fix is to pass host-specific conditions via job overrides or use a lookup table with global_vars. Another pattern: write templates that accept conditions as parameters, then supply the actual job names at instantiation. This keeps your DRY approach intact while ensuring conditions resolve correctly at runtime.

// io.thecodeforge — devops tutorial
// Correct parameterized condition via global_vars
template: ETL_STAGE
job_name: ETL_STAGE_US_1
condition: "done(DB_SYNC_US_1)"
global_vars: {REGION: "US"}