DevOps Intermediate

ON HOLD vs ON ICE in AutoSys — The Critical Difference

Q: What is the difference between ON_HOLD and ON_ICE in AutoSys?

When you release a job from ON_HOLD, it starts immediately if its starting conditions are currently met. When you release from ON_ICE, it waits for conditions to reoccur in the next scheduling cycle — it won't start immediately even if conditions are true.

Q: Which is safer to use — ON_HOLD or ON_ICE?

ON_ICE is generally safer when you want to skip a current run and resume normally. ON_HOLD is better when you plan to manually trigger the job as soon as the hold is released. The choice depends on your intent.

Q: Can you FORCE_STARTJOB a job that is ON_ICE?

In most AutoSys versions, you cannot force-start a job that is ON_ICE. You must first take it off ice, then force-start it. This is different from ON_HOLD, where a force-start event can often override the hold.

Q: Does putting a BOX on hold affect the jobs inside?

Yes. When a BOX job is placed ON_HOLD or ON_ICE, the box cannot enter RUNNING state, so none of its inner jobs can start. The hold effectively applies to the entire box contents.

Q: What is the status code for ON_HOLD and ON_ICE in autorep?

ON_HOLD shows as OH in autorep status output. ON_ICE shows as OI.

Q: How do I check event history to see who put a job on hold?

Use `autorep -J jobname -w -r` to view event history. You can also check AutoSys logs or the database table view `UJO_EVENT` if you have access.

📅 March 19, 2026 ⏱ 3 min read 🎯 Intermediate

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

📍 Part of: AutoSys → Topic 21 of 30

AutoSys ON_HOLD and ON_ICE look similar but behave very differently when released.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

AutoSys ON_HOLD and ON_ICE look similar but behave very differently when released.

ON_HOLD (OH): releasing runs the job immediately if conditions are currently met — use for manual-release scenarios
ON_ICE (OI): releasing waits for conditions to reoccur in the next cycle — use for skipping the current run and resuming normally
This is one of the most common AutoSys interview questions — the release behaviour difference is what matters

thecodeforge.io

ON_HOLD vs ON_ICE

Autosys On Hold Vs On Ice

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

⚡Quick Answer

ON_HOLD (OH): job is frozen; release means it starts immediately if conditions are currently true
ON_ICE (OI): job is deeply suspended; release waits for conditions to reoccur in the next cycle
Key difference: time conditions are evaluated ONCE under ON_ICE, but are currently true under ON_HOLD
Production impact: using ON_HOLD when you meant ON_ICE can cause a job to run outside its window
Most common mistake: assuming both behave the same on release — they don't

AssumptionThe team assumed that releasing from ON_ICE would behave like ON_HOLD — the job would start immediately since its scheduled time had passed.

Root causeThe job was put ON_ICE during a maintenance window at 1:30 AM. At 2:30 AM, after release, the team expected it to run. But ON_ICE does not evaluate time conditions as 'currently true' — it waits for the next occurrence of the condition (the next day at 2 AM).

Fix1. Take job off ice: sendevent -E JOB_OFF_ICE -J daily_settlement 2. Force a one-time run using sendevent -E JOB_ON_HOLD? Not possible while on ice. Instead, after OFF_ICE, manually trigger the job with sendevent -E FORCE_STARTJOB -J daily_settlement (if allowed) or wait for next scheduled run. 3. The real fix: use ON_HOLD for manual-release scenarios; ON_ICE only for skipping a period.

Key Lesson

ON_ICE does NOT run the job immediately on release even if the scheduled window is past.Always ask: do we want this job to run now (ON_HOLD) or next period (ON_ICE)?Train your team on the difference — it's the #1 AutoSys interview question for a reason.

Production Debug Guide

Symptom → Action for stuck jobs

Job shows ST: OH in autorep→Review why it was put on hold. If safe, release with JOB_OFF_HOLD and monitor if it runs immediately.

Job shows ST: OI in autorep→Understand context. If you want it to run now, release with JOB_OFF_ICE, but be aware it may wait for next cycle.

Downstream job stuck in WAITING→Check all predecessors with autorep -J <jobname> -q. Look for OH or OI status among ancestors.

Box job shows OH/OI, inner jobs never start→Release the box first with appropriate OFF event. Inner jobs may then run based on their own conditions.

FORCE_STARTJOB fails when job is ON_ICE→In most versions, you cannot force start a job that is ON_ICE. Use JOB_OFF_ICE first, then try force start.

ON_HOLD and ON_ICE are the two ways to suspend a job in AutoSys. They're often confused because both stop a job from running — but their release behaviour is completely different, and choosing the wrong one in a production recovery scenario can cause jobs to either run unexpectedly or not run until the next day. Get this distinction right.

ON_HOLD — suspend and resume at current conditions

When a job is ON_HOLD, it is frozen in its current state. If you put a job on hold while its starting conditions were already met, releasing it (OFF_HOLD) will cause it to start immediately — the conditions are still true.

on_hold.sh · BASH

1234567891011

# Put a job on hold
sendevent -E JOB_ON_HOLD -J daily_report

# Release from hold — starts immediately if conditions are met
sendevent -E JOB_OFF_HOLD -J daily_report

# Put an entire BOX on hold (and all inner jobs)
sendevent -E JOB_ON_HOLD -J eod_processing_box

# Check if a job is on hold
autorep -J daily_report   # shows OH status

▶ Output

Job Name ST Exit
daily_report OH -- <- ON_HOLD — conditions may already be met

/* After JOB_OFF_HOLD: */
/* If start_times was 02:00 and it's now 03:00 — job starts immediately */

⚠ Releasing ON_HOLD can start a job immediately

If you hold a job after its scheduled start time passes, releasing it with OFF_HOLD will start it immediately because the time condition is already past. This catches people off guard. If you want the job to wait until the next day's scheduled run, use ON_ICE instead.

📊 Production Insight

Releasing a held batch job at 3 AM when it normally runs at 2 AM will kick it off right away.

This can trigger unintended downstream processes or hit resource constraints.

Rule: always verify current time against start_times before using OFF_HOLD during production recovery.

🎯 Key Takeaway

ON_HOLD is a pause button.

Release runs the job now if conditions are true.

You must know the current time relative to start_times before releasing.

When to use ON_HOLD vs ON_ICE

IfYou need the job to run manually as soon as you release it

→

UseUse ON_HOLD — it's designed for manual release scenarios

IfYou want to skip the current run and resume at next scheduled time

→

UseUse ON_ICE — it completely resets the condition cycle

IfYou are not sure when you will lift the hold

→

UseUse ON_ICE — safer because the job won't run unexpectedly at odd hours

ON_ICE — suspend and wait for next condition cycle

When a job is ON_ICE, it's more deeply suspended. When you release it (OFF_ICE), the job does NOT start immediately — it waits for its conditions to become true in the next scheduling cycle.

For a job with start_times: '02:00', releasing it from ON_ICE at 3 AM means it won't run until the next scheduled 2 AM — it waits for the condition to reoccur, not to re-evaluate it as currently true.

on_ice.sh · BASH

12345678

# Put a job on ice
sendevent -E JOB_ON_ICE -J weekly_reconcile

# Release from ice — waits for conditions to reoccur (next cycle)
sendevent -E JOB_OFF_ICE -J weekly_reconcile

# Check if a job is on ice
autorep -J weekly_reconcile   # shows OI status

▶ Output

Job Name ST Exit
weekly_reconcile OI -- <- ON_ICE

/* After JOB_OFF_ICE at 03:00 (job normally runs at 02:00): */
/* Job waits until NEXT scheduled 02:00 — does NOT run at 03:00 */

📊 Production Insight

ON_ICE is forgiving during production incidents.

You can safely put a job on ice and forget it — it won't run until its next normal window.

But be careful: if the job has dependencies, those downstream jobs might also be blocked.

🎯 Key Takeaway

ON_ICE is a complete reset.

Release does NOT run the job now — it waits for the next scheduled time.

Use ON_ICE when you want to skip a run and resume normally.

Which to use when

The decision is simple once you understand the release behaviour:

Use ON_HOLD when: You want to delay a job temporarily and start it manually when ready. Maintenance windows. Jobs you want to run manually at a specific moment after releasing.

Use ON_ICE when: You want to skip a job for the current scheduling period and have it resume at its next normal scheduled time. Disabling a job for a few days without permanently modifying its definition. Safe suspension when you're not sure when you'll release it.

hold_vs_ice_decision.sh · BASH

1234567891011

# Scenario 1: Emergency maintenance, want to run job manually when done
# Use ON_HOLD — releases will start immediately when ready
sendevent -E JOB_ON_HOLD -J daily_settlement
# ... do maintenance ...
sendevent -E JOB_OFF_HOLD -J daily_settlement   # starts now

# Scenario 2: Job has a bug being fixed, skip today's run
# Use ON_ICE — releases will wait for tomorrow's scheduled run
sendevent -E JOB_ON_ICE -J daily_settlement
# ... fix deployed by end of day ...
sendevent -E JOB_OFF_ICE -J daily_settlement   # runs tomorrow at 02:00 as normal

📊 Production Insight

Mixing up these two in a P1 incident leads to either a job running too early or missing its window.

Teams often apply ON_ICE when they actually need ON_HOLD, then wonder why the job doesn't start.

Rule: decide based on when you want the job to run after release — now or next period.

🎯 Key Takeaway

ON_HOLD for manual release now.

ON_ICE for automatic release next cycle.

Pick based on timing, not habit.

How ON_HOLD and ON_ICE affect dependencies

Both statuses affect downstream jobs that depend on the held/frozen job.

When a job is ON_HOLD, it cannot reach SUCCESS or FAILURE, so any downstream jobs that wait for it (via conditions) will remain in a pending state. Releasing from ON_HOLD will start the job, and once it completes, the downstream jobs will then run.

When a job is ON_ICE, same effect — it cannot complete, so dependents wait forever until the job is taken off ice and eventually runs.

The difference: if you put a job ON_HOLD and it already satisfied its own conditions, it will run immediately on release — downstream jobs start soon. If you put it ON_ICE, the job still needs to wait for its next condition cycle, so downstream jobs stay waiting longer.

dependency_impact.sh · BASH

12345678910

# Job B depends on Job A
autorep -J Job_B   # Shows status: WAITING (because Job A is ON_HOLD or ON_ICE)

# If Job A is ON_HOLD and you release it:
sendevent -E JOB_OFF_HOLD -J Job_A
# Job A runs now -> succeeds -> Job B starts

# If Job A is ON_ICE and you release it:
sendevent -E JOB_OFF_ICE -J Job_A
# Job A waits until next scheduled time -> only then runs -> Job B waits even longer

🔥Dependencies can mask a held job

If you see a downstream job stuck in WAITING, it might not be the job itself — check if any of its direct or indirect predecessors are ON_HOLD or ON_ICE. That's the real root cause.

📊 Production Insight

We once spent two hours debugging a stuck batch chain.

The root cause was a predecessor job that had been ON_ICE for days by a different team.

Rule: always run autorep with dependency recursion when troubleshooting stalled pipelines.

🎯 Key Takeaway

Both ON_HOLD and ON_ICE block downstream jobs.

The difference is how soon the blocked job runs after release.

Diagnose stuck chains by checking predecessors' status first.

Debugging jobs that won't start — hold/ice troubleshooting

When a job doesn't start and you suspect a hold or ice status, follow these steps:

Run autorep -J jobname and look for ST column — OH or OI indicates the job is held/iced.
Check the status of any parent box: autorep -J boxname — if the box is OH/OI, inner jobs are blocked even if they look normal.
Review sendevent history to see who set the hold/ice: check autorep logs or event trail.
If a box is held and you release it, inner jobs might start immediately based on their own conditions — be cautious.

To clear a hold: sendevent -E JOB_OFF_HOLD -J jobname To clear ice: sendevent -E JOB_OFF_ICE -J jobname

debug_hold_ice.sh · BASH

12345678910111213

# Check job status
autorep -J daily_report
# Output: ... ST: OH ... -> ON_HOLD

# Check box status (inner jobs may be blocked)
autorep -J batch_box

# Check event history (if available)
autorep -J daily_report -w -r

# Force a job ON_HOLD if it's ON_ICE? Not possible directly; must clear ice first.
sendevent -E JOB_OFF_ICE -J daily_report
# Then optionally set hold: sendevent -E JOB_ON_HOLD -J daily_report

📊 Production Insight

A job stuck in OH status for hours is often a sign someone forgot to release it.

Automated monitoring should alert on jobs in OH or OI for more than X minutes.

Don't rely on manual checks — set up a simple cron to autorep and flag held jobs.

🎯 Key Takeaway

OH and OI in autorep are easy to spot.

Always check parent box status too.

Automate alerts for held jobs — they are silent failures.

🗂 Complete comparison: ON_HOLD vs ON_ICE

Aspect	ON_HOLD (OH)	ON_ICE (OI)
Status code	OH	OI
How to set	sendevent -E JOB_ON_HOLD	sendevent -E JOB_ON_ICE
How to release	sendevent -E JOB_OFF_HOLD	sendevent -E JOB_OFF_ICE
After release behaviour	Starts immediately if conditions currently met	Waits for conditions to reoccur in next cycle
Use case	Temporary hold, manual release when ready	Skip current period, resume at next scheduled time
Risk if misused	Job starts unexpectedly after release	Job misses current run entirely
Impact on dependencies	Downstream jobs blocked until held job completes	Same, but release delay may be longer (next cycle)
Can FORCE_STARTJOB override?	Often yes (depending on version)	Usually no — must release ice first

🎯 Key Takeaways

ON_HOLD (OH): releasing runs the job immediately if conditions are currently met — use for manual-release scenarios
ON_ICE (OI): releasing waits for conditions to reoccur in the next cycle — use for skipping the current run and resuming normally
This is one of the most common AutoSys interview questions — the release behaviour difference is what matters
Setting a box ON_HOLD also holds all inner jobs; same for ON_ICE
Always check parent box status when debugging stuck jobs — OH/OI on the box blocks everything inside

⚠ Common Mistakes to Avoid

✕Putting a job ON_HOLD expecting it to wait until the next scheduled run

Symptom

Job runs immediately after OFF_HOLD because conditions are currently met, causing it to execute outside its intended window.

Fix

Use ON_ICE instead if you want the job to skip this run and resume at the next scheduled time.

✕Putting a job ON_ICE when you need it to run manually after release

Symptom

After OFF_ICE, the job does not run; it waits until the next scheduled cycle. You can't force start it either (in most versions).

Fix

Use ON_HOLD if you plan to manually trigger the job after releasing the hold.

✕Forgetting a job is ON_ICE and wondering why it's not running for days

Symptom

Job remains in OI status indefinitely; no one notices because there's no alert.

Fix

Set up monitoring for jobs in OH/OI status for more than a few hours. Send automated reminders.

✕Using ON_HOLD on a box job without understanding it puts all inner jobs on hold too

Symptom

Inner jobs never start even though their individual status looks fine.

Fix

Always check box status when troubleshooting stalled jobs. Release the box with JOB_OFF_HOLD or JOB_OFF_ICE.

Interview Questions on This Topic

QWhat is the difference between ON_HOLD and ON_ICE in AutoSys?JuniorReveal
ON_HOLD suspends a job but retains the current time condition — releasing it with OFF_HOLD will start the job immediately if the start time has already passed. ON_ICE also suspends the job but resets the time condition — releasing with OFF_ICE makes the job wait for the next occurrence of its start time. In short: ON_HOLD = pause/resume; ON_ICE = skip/cycle wait.
QIf you release a job from ON_HOLD at 3 AM when its scheduled time was 2 AM, what happens?JuniorReveal
The job starts immediately because the time condition (2 AM) is already in the past and is still considered satisfied. The job runs right away at 3 AM.
QIf you release a job from ON_ICE at 3 AM when its scheduled time was 2 AM, what happens?JuniorReveal
The job does NOT start immediately. It waits for the next scheduled occurrence of its start time — the next day at 2 AM. ON_ICE completely resets the condition cycle.
QWhen would you use ON_ICE instead of ON_HOLD?Mid-levelReveal
Use ON_ICE when you want to skip the current run and have the job resume at its next scheduled time. Examples: a job has a bug that will be fixed before tomorrow's run; you want to disable a job for a few days without modifying its JIL. Use ON_HOLD when you plan to manually release the job as soon as the hold is removed.
QWhat AutoSys status code represents ON_HOLD and ON_ICE?JuniorReveal
ON_HOLD is represented by OH, ON_ICE by OI in the autorep status output.
QCan you FORCE_STARTJOB a job that is ON_ICE?SeniorReveal
In most AutoSys versions, you cannot. You must first release it from ON_ICE (JOB_OFF_ICE) and then force start it. This is an important distinction from ON_HOLD, where FORCE_STARTJOB often works even while the job is on hold.

Frequently Asked Questions

What is the difference between ON_HOLD and ON_ICE in AutoSys?

When you release a job from ON_HOLD, it starts immediately if its starting conditions are currently met. When you release from ON_ICE, it waits for conditions to reoccur in the next scheduling cycle — it won't start immediately even if conditions are true.

Which is safer to use — ON_HOLD or ON_ICE?

ON_ICE is generally safer when you want to skip a current run and resume normally. ON_HOLD is better when you plan to manually trigger the job as soon as the hold is released. The choice depends on your intent.

Can you FORCE_STARTJOB a job that is ON_ICE?

In most AutoSys versions, you cannot force-start a job that is ON_ICE. You must first take it off ice, then force-start it. This is different from ON_HOLD, where a force-start event can often override the hold.

Does putting a BOX on hold affect the jobs inside?

Yes. When a BOX job is placed ON_HOLD or ON_ICE, the box cannot enter RUNNING state, so none of its inner jobs can start. The hold effectively applies to the entire box contents.

What is the status code for ON_HOLD and ON_ICE in autorep?

ON_HOLD shows as OH in autorep status output. ON_ICE shows as OI.

How do I check event history to see who put a job on hold?

Use autorep -J jobname -w -r to view event history. You can also check AutoSys logs or the database table view UJO_EVENT if you have access.

🔥

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