What Should a Nightly Automation Email You?

What should a nightly automation email you?

A report you can read in ten seconds when everything is fine, and nothing that pretends to be an alarm. The nightly email exists so you know the system ran and what it did. It is not the channel for telling you something is on fire, and treating it as one is why most people stop reading theirs.

Almost every automation I inherit has this backwards. It sends nothing on a good night and a wall of red text on a bad one, which means the only evidence that anything is working is the absence of mail.

Here is what I put in that email, what I deliberately leave out, and where the urgent things should actually go.

Why is email the wrong place for an alert?

Because the people who have studied this at scale say so plainly. Google's Site Reliability Engineering book states that email alerts are of very limited value and tend to easily become overrun with noise, and it keeps pages to humans distinct from ticket or email alerts, which accumulate lower priority issues.

That matches what happens in small businesses exactly. An automation emails a warning, nobody acts on it, the next warning arrives, and within a month the rule that files them into a folder has been written. The information is still being produced and nobody is receiving it.

So the email is not where you put the thing that needs a response tonight. It is where you put the thing you want to be able to check tomorrow, which is a different and genuinely useful job.

What is the nightly email actually for?

Proof of life and a record. Its first job is to tell you the run happened at all, because a job that silently stops running is the failure mode nothing else catches. Its second job is to give you a dated history you can scroll back through when someone asks what changed last Tuesday.

That second job is worth more than people expect. Six weeks after a client reports something odd, an inbox full of nightly summaries is the cheapest audit log you will ever have, and it costs nothing to produce.

It has a third job on client work. It is visible evidence that the thing they are paying for is running, which quietly removes a whole category of awkward conversation. I wrote about the broader version of that in giving clients read only visibility into an automation.

What belongs in the subject line?

The verdict and the number, in that order, so the email can be judged without opening it. Something like a status word, the date, and the count of records processed. If your subject lines are identical every night, you have built something nobody can triage from a phone screen.

Put the status word first because that is what survives truncation on a mobile lock screen. A subject that begins with the automation's name and buries the outcome at the end is a subject that will be read as noise.

Keep the vocabulary small and stable. Two or three words that never change, used consistently, so that over time you recognise an unusual subject line without reading it. Novelty in the subject should mean novelty in the system.

What numbers should it carry?

The ones that describe what happened, not the ones that explain why. The SRE guidance is to monitor what is broken rather than why, and the same discipline keeps a nightly digest short. Counts in, counts out, counts skipped, counts failed, and how long the run took.

Google's four golden signals for user facing systems are latency, traffic, errors and saturation, and that translates surprisingly cleanly to a marketing automation. How long the run took is latency. How many records arrived is traffic. How many failed is errors. How close you came to a quota or a rate limit is saturation.

Anything beyond those four belongs in a log rather than an email. The temptation is to include the detail because you have it, and every field you add is a field that makes the summary slower to read, which is the only thing that can kill it.

What should it say when nothing happened?

That nothing happened, explicitly, with the same numbers as always. A quiet night should produce a quiet email, not silence. Silence is ambiguous, and an ambiguous signal is worse than no signal because you will eventually decide it means success.

This is the single change that improves most automation setups. Send the boring one. Send it at the same time every night, with the same shape, so a missing email becomes information in itself.

The automation I run for Ajust moves case data between Airtable and Webflow through WhaleSync, and the pipeline behind it has delivered more than 25,000 cases and saved more than 50,000 hours. The thing that keeps it honest is not clever error handling. It is that a summary lands every day whether or not there is anything to report.

How do you keep it from becoming noise?

By refusing to put anything in it that asks for a decision. The moment a digest contains three warnings that somebody is supposed to evaluate, you have built an alert with a report's job title, and it will be ignored on exactly the same schedule as every other alert.

The SRE guidance is useful here even though it is written about pagers. It says every page should be actionable, that every page response should require intelligence, and that if a page merely merits a robotic response it should not be a page. Run the same test on your digest in reverse. If a line in it requires action tonight, it does not belong in the digest.

One practical rule has served me well. A nightly email should be readable in under ten seconds, and if it is not, the fix is to move detail out rather than to reformat it.

Where should the urgent things go instead?

Into a channel with a person attached and a threshold that means something. For most small teams that is a message in a chat tool, routed to one named owner, triggered only by conditions you have decided in advance are worth interrupting someone for.

The threshold is the hard part and it is worth arguing about. The SRE material says pages should be about a novel problem or an event that has not been seen before, and that a responder should be able to react with a sense of urgency. If your automation interrupts someone for a condition that recurs weekly, you have taught them to dismiss it.

The failures worth interrupting for are usually the ones that leave data in a bad state rather than the ones that stop cleanly. I went through those in monitoring silent automation failures, and they are the reason a digest alone is not enough.

Does this change when money is involved?

Yes, and it changes in one direction only, which is more detail retained rather than more detail emailed. An automation that moves money or writes to a billing system needs a record of every individual action, and an email is the wrong container for that.

The nightly email should still be a summary, with totals rather than transactions, and a pointer to where the full record lives. The HubSpot automation I run for Kismet Health through Zapier is not a billing system, but the same principle applies to anything writing into a CRM that a sales team trusts.

What to keep and for how long is a separate decision, and a more consequential one than people expect. I set out my approach in what to log when an automation touches money.

What should you do next?

Open the last nightly email your automation sent you and time how long it takes to answer one question: did it work. If you cannot answer in ten seconds, rewrite the subject line and the first three lines this week, and delete everything that asks you to decide something.

Then make sure a quiet night still produces an email. That one change turns your inbox from a place where problems shout into a place where absence is meaningful, which is the entire point of the exercise.

After six years of running automations that nobody watches most days, the pattern is consistent. The systems I trust are the ones that tell me they are fine, in the same words, every single day. If you have something running unattended and no idea what it would say tonight, reach out and let's chat about it.