What error alerts to ask for when a freelancer builds your automation

The short answer

When you brief an automation, “it should alert me if something goes wrong” is not enough. Most broken automations never raise an error. They skip a run, or they run and do nothing, and the log says everything finished normally. An alert that only fires on errors stays silent through exactly those failures.

So ask for alerts on three things, not one: a run that failed, a run that did not happen, and a run that finished with nothing. Then specify who receives them, what each message must say, and how you will test them before final payment. Five lines in the brief cover it, and they fit under the “Failure behaviour” field of the workflow automation brief.

Why “alert me on errors” is not enough

I run a set of unattended publishing and content jobs on a schedule. Over a few months they stopped working several times. Here is how each of those failures looked from the outside:

What happened	What the system reported
A login token for the file host expired; five publishing slots over two days produced nothing	Every scheduled run finished with a success code
The queue got stuck behind one item that could not be prepared, and publishing stopped overnight	The log said “nothing to publish”, a normal exit
A system update restarted the computer at night; three overnight slots and the morning check never ran	Nothing at all. No run, so no log line
The machine went into standby, and scheduled runs started up to three hours late	Nothing. The runs eventually succeeded, just late

None of these would have triggered an “on error” alert. The first one is the most instructive: the step that failed treated the expired login as a permanent error and correctly decided not to retry, the scheduler recorded success because the wrapper script exited cleanly, and the daily check did not look at logins. Every part behaved as designed. The design simply had no alert for “a run finished but published nothing”.

The five alert lines to put in the brief

Line 4 is the cheapest to add and catches the most common silent stop. A daily publishing job of mine checks its code-hosting login on every run, including the days when nothing is due. The point is to hear about an expired token days before a publish needs it, not on the morning nothing appears.

Line 2 is the one buyers forget. A job that never starts cannot report on itself, so something outside it has to notice. That check is often called a watchdog or a heartbeat; the basics page on heartbeat monitoring explains the idea in plain words.

What each alert message must say

An alert that says “workflow failed, check the logs” is close to useless when you are away from the computer, and away is exactly when unattended jobs matter. That is why my catch-up alert carries the time of the empty slot and the error it saw, not a pointer to a log file. A good alert answers four questions in the message itself:

• Which run: the job and the scheduled time it was for.
• What failed: the step, and the error in a short readable form (“login expired”, “network unreachable”), not a stack trace.
• What already happened: did it retry, and is another attempt scheduled?
• What to do first: the one action that usually fixes it, or “nothing, it will retry at 15”.

After the token incident, the fix on my side was exactly this: on a permanent failure, each slot now sends a message straight away that includes the command to fix the login.

Alerts that people stop reading

Alerts have a failure mode of their own: they get ignored. Three things cause it, and all three are worth a sentence in the brief.

Noise. A message for every successful run teaches you to swipe the channel away. My morning check messages only when something looks wrong; each publish already sends its own short confirmation, and a second “all good” would only dilute it.

False alarms. On its first day, my morning check raised two false alarms: one because a single status lookup bounced, one because it read a count from text output that came back in a different encoding. Both were fixed (retry the lookup three times before reporting, count the state file directly instead of parsing text). On another day a test I ran by hand sent a real-looking alarm to my phone. Test runs no longer send messages. One false alarm makes you trust the next real one less, and an alert you do not trust is not an alert.

Wrong verdicts. Once a publishing step got an ambiguous error back, reported “publish failed”, and the alert faithfully delivered that, even though the post had actually gone out. The job now checks the account for the post before declaring failure. Ask the freelancer: before an alert says something failed, does the automation check the actual result?

Where the watchdog runs matters

One more lesson, and it is the subtle one. My morning check once failed together with the jobs it was watching. A system update restarted the computer overnight, nobody logged back in, and the scheduled jobs that needed a logged-in session did not run, including the check. The watcher had the same weak point as the thing it watched.

You do not need to understand the details to ask the right question: “If the machine or server that runs this goes down, what still runs to tell me?” A good answer names something that does not share the same machine, account or login, even if it is just a free uptime service that expects a ping each morning. The field note on scheduled jobs and sleep mode shows how quiet this kind of outage looks.

Test the alerts before you pay

Alerts are part of the delivery, so they belong in acceptance. The acceptance checklist for unattended automations has the full list; for alerts specifically:

1. Force a failure. Remove an input or revoke a token. The alert reaches you, on your channel, within the time in the brief, and says what failed.
2. Skip a run. Disable the schedule for one slot or switch off the machine. The missed-run alert arrives the next day.
3. Starve it. Give it a run with nothing to do where it normally has work. The empty-result alert fires, or the freelancer explains why that case is normal.
4. Leave it alone for three days. No messages, except the ones you agreed on.

Test 2 is the one most buyers skip, and it tests the failure that hurts most. If the freelancer has to add something to make it pass, that is a good outcome: it was missing.

Wrap-up

Ask for alerts on failures, missed runs and empty results; send them to you with enough in the message to act on; keep the channel quiet when things are healthy; and make sure the thing that watches does not share the weak points of the thing it watches. Then break it on purpose before you pay. When you agree maintenance terms, the alert is what turns “it stopped a week ago” into “it stopped this morning, here is the error”.