Junior
3 min · March 19, 2026
AutoSys alarm_if_fail Defaults to 0 — Silent Failures
alarm_if_fail defaults to 0 in AutoSys JIL.
⚡Quick Answer
- AutoSys alarms raise alerts in Event Server on job failures, long-running jobs, or machine issues — alarm_if_fail: 1 enables failure alarms
- Key components: alarm_if_fail (job failure), max_run_alarm (long runtime), min_run_alarm (suspiciously fast), alarm_if_terminated (killed jobs), alarm_on_missing (machine offline)
- Performance impact: Alarms stored in Event Server DB; excessive alarms cause database bloat and UI slowdowns — aggregate, don't alert per instance
- Production trap: alarm_if_fail: 0 is default — a silent failure overnight means no one knows until customers complain
- Biggest mistake: Sending failure emails to unmonitored shared mailbox — alarms without response process are no alarms at all
Plain-English First
AutoSys alarms are the smoke detectors of your batch environment. When something goes wrong — a job fails, a machine goes offline, a job runs for too long — the alarm fires and the right people get notified before the problem becomes a crisis.
AutoSys has a built-in alarm system that lets you define exactly what events should trigger alerts and who should be notified. Without alarms, your batch jobs could silently fail overnight and nobody would know until users start reporting missing reports in the morning. With well-configured alarms, your team knows within minutes.
But alarms are dangerous. Set them too broadly and your team ignores them (alarm fatigue). Send them to the wrong mailbox and nobody reads them. Default alarm_if_fail: 0 means your critically important job fails every night at 2am and nobody ever hears about it.
By the end you'll know how to set up job failure alarms, email notifications, machine monitoring, and runtime bounds alerts. You'll also know the specific mistakes that cause alarms to be ignored or to never fire at all.
alarm_if_fail — the basic failure alert
The simplest alarm is alarm_if_fail. Set it to 1 on any job, and AutoSys raises an alarm in the Event Server when that job fails. You can then configure alarm actions to send email, page, or invoke a script.
Production Insight
alarm_if_fail: 0 is the default. Many legacy jobs were defined without it and have been failing silently for years.
Run an audit:
autorep -J % -q | grep -B5 alarm_if_fail | grep -v alarm_if_fail: 1 to find jobs without failure alarms.Rule: Every production job should have alarm_if_fail: 1 unless explicitly documented as non-critical.
Key Takeaway
Set alarm_if_fail: 1 on all critical jobs — the default is 0 (no alarm). Run annual audits to ensure compliance.
Use max_run_alarm and min_run_alarm for runtime bounds alerts; min_run_alarm catches jobs that end too fast (possible logic error).
Rule: A failure without an alarm is a silent outage. Configure alarms before the first production run.
Alarm Configuration Decision Tree
IfJob is critical (financial, customer-facing, compliance)
→
UseSet alarm_if_fail: 1, max_run_alarm: p99 runtime + 20%, notification_emailaddress to on-call group
IfJob is non-critical but should be monitored
→
UseSet alarm_if_fail: 1 but send email to team mailbox (not pager). Review failures daily.
IfJob runtime varies significantly (data-dependent)
→
UseSet max_run_alarm high (e.g., 4x median runtime) to avoid false positives. Use term_run_time if you want to kill hung jobs instead.
IfJob is part of a box that handles retries
→
UseAlarm only if box fails, not individual job. Set alarm_if_fail: 1 on box, 0 on child jobs to reduce noise.
IfJob is expected to fail occasionally (e.g., file not found, retried later)
→
UseDo NOT set alarm_if_fail on job. Set alarm at parent workflow level only after retries exhausted.
Notification attributes — email on failure
For direct email notification without configuring a separate alarm action, use the notification attributes. These send an email when the job fails.
Notification message variables
AutoSys supports variables in notification_msg: %s = job name, %m = machine name, %t = timestamp, %x = exit code. Use these to make your alert emails informative enough that the on-call engineer knows what failed and where to look.
Production Insight
notification_msg_on_failure should always include the log file path and exit code. Without these, the on-call engineer has to log into AutoSys, find the job, find the machine, then find the log.
The %x (exit code) variable is often omitted but it's the single most useful piece of information for triage.
Rule: Include %s, %m, %x, and the full path to the job's log file in every failure notification. The engineer should not have to look anything up.
Key Takeaway
Use notification_emailaddress for direct email alerts; include log file paths and exit code (%x) in notification_msg.
Sending to a shared mailbox nobody monitors defeats the purpose — alarms need a response process.
Rule: notification_emailaddress should point to a pager or SMS gateway for critical jobs, not just an internal mailbox.
Machine and system alarms
Beyond job-level alarms, AutoSys can alarm on machine events — when an agent goes MISSING or when the Event Processor has issues.
Production Insight
A machine that goes MISSING is worse than a job failure — it affects all jobs on that machine. Yet many sites don't monitor it.
alarm_on_missing: 1 should be set on every production machine. When a machine goes offline, all running jobs on it fail immediately.
Rule: Configure machine alarms before deploying new agents. Add to standard machine template:
update_machine: new_host alarm_on_missing: 1.Key Takeaway
Set alarm_on_missing: 1 on all production machines — a missing agent takes down all jobs on that host.
Use autorep -a to view active alarms; ALARM_ACK acknowledges without fixing root cause.
Rule: Alarms without an acknowledgement process are just noise. Assign ownership and track resolution.
● Production incidentPOST-MORTEMseverity: high
The Silent Friday Night Payroll Failure
Symptom
The payroll job ran every Friday at 2am. On this Friday, the script failed due to a database connection timeout. AutoSys logged the failure, marked the job status as FAILURE, and stopped. No alarm fired. No email was sent. The team didn't know until Monday morning when the finance department asked why payroll hadn't run. The job could have been re-run in 20 minutes, but the team lost the entire weekend window.
Assumption
The team assumed that AutoSys automatically alerted on job failures. They didn't know that alarm_if_fail defaults to 0. They also assumed that because they had a dashboard, someone would notice. But no one checked the dashboard over the weekend. They also had no runbook for monitoring auto-recovery or fallback alerts.
Root cause
The job definition JIL file lacked
alarm_if_fail: 1. It was omitted entirely, and the default is 0 (no alarm). The team had configured email notifications for successful completion but not for failures. The operations team monitored the dashboard only during business hours. The failure alert was never triggered, and the on-call engineer had no way of knowing about the failure. The job was critical but treated as non-critical in the alarm configuration because no one had reviewed the JIL defaults.Fix
1. Updated the job definition:
alarm_if_fail: 1.
2. Added notification_emailaddress: payroll-ops@company.com and notification_msg_on_failure: "Job %s failed on %m at %t with exit code %x. Check log /logs/autosys/payroll_run.err".
3. Added a separate max_run_alarm: 60 to detect hung jobs.
4. Configured the on-call rotation to include weekend coverage with pager duty integration.
5. Added a weekly audit script that lists all jobs with alarm_if_fail: 0 and flags them for review.Key lesson
- alarm_if_fail: 0 is the default. You must explicitly set it to 1 on every critical job. Do not assume AutoSys alerts on failure.
- A failure without an alarm is a silent outage. Review all JIL files annually to ensure critical jobs have alarms enabled.
- Dashboards are not alarms. If no one is looking at the dashboard when the failure occurs, it's not monitoring.
- Document the on-call escalation process. The failure alert must reach a human, not just a log file.
Production debug guideSymptom → Action mapping for common alarm failures in AutoSys environments.5 entries
Symptom · 01
Job failed but no alarm/email received — outage went undetected
→
Fix
Check if alarm_if_fail: 1 is set. Default is 0 (no alarm). Modify JIL:
update_job: job_name alarm_if_fail: 1. Also check notification_emailaddress and notification_msg.Symptom · 02
Too many alarms — team stopped paying attention (alarm fatigue)
→
Fix
Reduce alarm volume. Only alarm on critical jobs. Use max_run_alarm and min_run_alarm for bounds alerts, but set thresholds high enough to avoid frequent firing. Consider aggregating non-critical failures into daily summary report instead of real-time alerts.
Symptom · 03
Alarms acknowledged but root cause not fixed — repeating alarms
→
Fix
Implement alarm resolution tracking. After acknowledging, assign ticket number and require RCA. AutoSys can invoke script on alarm (alarm_action) to create ticket. Block new alarms for same job until ticket is resolved, or use different severity levels.
Symptom · 04
max_run_alarm triggers every night for long-running job — false positive
→
Fix
max_run_alarm threshold is too low. Increase it based on historical runtime p99 + 20%. For seasonal jobs, use conditional start conditions or multiple JILs with different thresholds.
Symptom · 05
Notification email not received — check failed but no alert
→
Fix
SMTP configuration in AutoSys may be misconfigured. Check
autorep -M for mailer status. Also check if notification_emailaddress contains spaces or invalid characters. Test with sendevent -E ALARM_TEST.★ AutoSys Alarm Debug Cheat SheetFast diagnostics for alarm issues in production AutoSys environments.
Job failed, no alarm — suspected missing alarm_if_fail−
Immediate action
Check job definition for alarm_if_fail attribute
Commands
Fix now
Update job:
update_job: job_name alarm_if_fail: 1 in JIL, then jil < update.jil or use sendevent -E UPDATE_JOB.Email notification not sent on failure+
max_run_alarm firing too often — false positives+
Alarm acknowledged but same alarm reappears next day+
Machine offline — alarm_on_missing not configured+
Key takeaways
1
Set alarm_if_fail
1 on all critical jobs — the default is 0 (no alarm). Run annual audits to ensure compliance.
2
Use notification_emailaddress for direct email alerts; include log file paths and exit code (%x) in notification_msg.
3
max_run_alarm and min_run_alarm provide bounds-based alerting for jobs running too long or suspiciously fast.
4
Set alarm_on_missing
1 on all production machines — a missing agent takes down all jobs on that host.
5
Alarms need a response process
sending to a shared mailbox nobody monitors defeats the purpose.
Common mistakes to avoid
5 patterns×
Not setting alarm_if_fail: 1 on critical jobs — expecting default to be 1
Symptom
Job fails silently over weekend. No alarm, no email. Team discovers failure when users complain Monday morning. Outage goes undetected for 48+ hours.
Fix
Update all production jobs:
update_job: job_name alarm_if_fail: 1. Run quarterly audit: autorep -J % -q | grep -B5 'alarm_if_fail:' | grep -v 'alarm_if_fail: 1' to catch missing alarms.×
Not including %x (exit code) and log path in notification_msg
Symptom
On-call engineer receives alert 'Job payroll_run failed' but has no idea why. They must log into AutoSys, find the job, find the machine, then grep for the log file. Triage takes 20 minutes instead of 2.
Fix
Add variables:
notification_msg: "Job %s failed on %m at %t with exit code %x. Log: /logs/autosys/%s.err". Include full absolute path to the log file.×
Sending alarms to unmonitored shared mailbox
Symptom
Alarms sent to batch-ops@company.com. The mailbox has 10,000 unread messages. No one notices new alarms. Failures go undetected.
Fix
Send critical alarms to pager/SMS gateway or ticketing system. For non-critical, send to team channel with expectation of daily review. Never send to a mailbox that is not actively monitored.
×
Setting max_run_alarm too low — false positives every night
Symptom
max_run_alarm: 30 minutes. Job normally takes 25 minutes but occasionally takes 35 minutes due to data volume. Alarm fires every night. Team ignores alarm. Real hung job goes unnoticed.
Fix
Set max_run_alarm to p99 runtime + 20% based on historical data. Use
autorep -J job_name -r -t to see runtime history. For seasonal jobs, use multiple JILs with different thresholds or conditional start times.×
Acknowledging alarm without fixing root cause
Symptom
Same alarm fires every day about same job. Team acknowledges it daily but never investigates. Becoming noise, eventually real alarm gets missed.
Fix
Implement alarm resolution tracking. Require ticket number and root cause analysis for each acknowledged alarm. Block new alarms for same job until ticket is closed. Use alarm_action to create ticket automatically.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
How do you configure AutoSys to send an email when a job fails?
Q02JUNIOR
What does max_run_alarm do?
Q03JUNIOR
What variables can you use in AutoSys notification_msg?
Q04JUNIOR
What does alarm_if_fail: 0 mean (the default)?
Q05JUNIOR
How do you acknowledge an AutoSys alarm?
Q01 of 05SENIOR
How do you configure AutoSys to send an email when a job fails?
ANSWER
Two methods: (1) Set
alarm_if_fail: 1 and configure notification_emailaddress and notification_msg. AutoSys sends email to the specified addresses when the job fails. The notification_msg can include variables %s (job name), %m (machine), %t (timestamp), %x (exit code). (2) Use alarm_action to call a custom script that sends email, pages, or creates a ticket. The alarm_action script receives the alarm details as arguments. The notification approach is simpler; alarm_action is more flexible for integration with ticketing systems or pager duty.FAQ · 5 QUESTIONS
Frequently Asked Questions
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