Let me describe a Monday that will feel familiar. Two scheduled jobs at a flight school picked the same weekend to misbehave — the sort of week that explains why the word AutomationOps has started showing up in operations conversations. A booking system sends confirmation emails through a small script, and it sends every confirmation twice. Separately, a reminder job meant to nudge students with overdue medical certificates runs against an empty filter result and — because the programmer wrote “if the list is empty, send to everyone” without realising it — emails all four hundred students at once. Nothing is on fire. Everyone is annoyed. And the person who wrote both scripts left for an airline two years ago.
If you have lived a version of this, here is the reassurance: the code was never the villain. It did precisely what it was told, once, by someone who could no longer be asked. What the school was missing has a name — AutomationOps, the craft of running scheduled automation like a production system rather than a junk drawer — and the good news is that the diagnosis takes an afternoon, not a reorganisation.
Three Symptoms That Keep Coming Back
Surprising scripts rarely surprise in new ways. Watch for these patterns in your own operation:
- The same failure twice. A job breaks, someone fixes it by hand, and three weeks later it breaks identically. That is not bad luck; it is a repair without a guard, and it will keep returning until the job itself changes.
- Scale without supervision. The script that safely updated five aircraft records in 2021 now updates five hundred, and nobody widened its testing to match its reach.
- Ownership fog. Ask three people who maintains the reminder job and you will get three different names, all of them wrong. Unowned automation is the load-bearing kind, always.
The AutomationOps Diagnosis: Rarely the Code
Run the diagnosis honestly and most incidents trace to the same short list. The job was never rehearsed, so its first real run was the test. It shared a login with everything else, so nobody could tell what acted. It had no boundary, so a small mistake travelled far. And it answered to nobody, so when it drifted — as unattended things do — the drift went unnoticed until a student complained. Those four gaps are what AutomationOps exists to close, and closing them is less about tooling than about deciding that repeats deserve the same care as first runs.
There is a related trap worth naming: automating a process before you understand it. If the human version of a task is messy, a script will execute the mess at machine speed. Clean the workflow first; the automation will thank you by being short enough to review.
The AutomationOps Decision Path: Four Questions
Before writing (or keeping) a scheduled job, walk it through a short decision path. The Atlas frames it as a tree, and it works just as well spoken aloud in a hangar:
- Has the task settled into a repeat you can describe? If nobody can sketch its steps on paper, automate nothing — document the work first, then revisit.
- Can the need be removed at the source? The best automation is a fix upstream: the duplicate bookings might vanish with a database constraint, no reminder script required.
- Does it need human judgement? Tasks with exceptions and nuance deserve a human-backed interface — the system proposes, a person approves — not a blind cron entry.
- Does it pay back, or is consistency the point? Honest arithmetic or a compliance requirement justifies the build. Neither means you skip the guardrails; it means the guardrails have something worth protecting.
Only a task that survives all four questions earns a place on the scheduler. That filter sounds strict, yet most teams who apply it discover they wanted fewer, better jobs — which is exactly the point.
Teach Your Scripts to Say “Already Done”
The single most valuable property you can give a repeat is idempotency: running it twice leaves the same result as running it once. The phrasing trick is to describe a state rather than an action — “ensure the aircraft record shows the new inspection date” instead of “update the record”. A state-describing job can safely re-run after a timeout, a network blip, or a curious colleague pressing enter twice.
Some actions cannot be made idempotent. Creating an account, charging a card, sending a message — these happen or they do not. For those, hand the caller a unique request ID and record it in the same breath as the action; if the ID is already present, refuse to repeat. It sounds like bureaucracy until you meet the alternative: a payment webhook that retried a charge because the first success reply was lost in transit.
Idempotent design also buys courage. Google’s repair jobs can re-run on a fifteen-minute cycle precisely because each run only nudges systems toward a desired state — there is no cumulative damage to fear from persistence. Test suites help you get there; Molecule’s default sequence for automation code includes an explicit idempotence check, so the property is verified rather than hoped for. Adopt the same habit in your own reviews: ask for proof the second run is harmless, and accept “it passed once” as unfinished work.
Small Rules That Absorb Bad Days
Round out the diagnosis with four cheap habits, each of which converts a catastrophe into a shrug:
- Treat zero targets as an error. When a job finds nothing to act on, halt and raise a flag. Empty must never be a synonym for “everybody”.
- Set a failure budget. One failure in a run should stop it. Retry logic belongs to designed recovery, not to a script stubbornly repeating a mistake at scale.
- Give each job its own identity. Distinct credentials per automation tell you exactly who did what, and let you revoke one without evicting all.
- Install the off switch before you need it. A per-job kill switch, plus one global switch above it, known to whoever carries the pager. Rehearse reaching both, because a switch nobody can find under pressure is decoration.
A Gentle Start for Your School or Team
Begin by listing every scheduled job you run and who wrote it — the list is always longer than expected, and that is the useful shock. Next to each entry, note what it touches and what a bad run would cost. Retire the orphans. If you want context on neighbouring practices while you work, the site’s primer on navigating the world of RobotOps and the guide to intelligent automation systems both pair well with this one, as does the overview of AIOps training and IT operations automation for the monitoring side of the house.
For the primary source, the Atlas’s entry on AutomationOps lays out the full decision path, the tier model and the guardrail set in careful detail — well worth ten minutes before you touch a crontab.
Keep the Friendly Half of Automation
None of this turns your operation into a robot factory, and that is the point. Automation should absorb the copy-paste work — the confirmations, the reminders, the roster syncs — so people are free for the judgement calls no script should make. AutomationOps simply insists that the absorbing be deliberate: rehearsed, bounded, owned, and stoppable. Your students will never see the difference on a good day. On the bad day, they will see a calm email explaining a brief delay instead of four hundred confused replies — and that difference is the entire return on an afternoon of diagnosis.
