What Should You Log When an Automation Runs?

What should you log when an automation runs?

Log enough to answer three questions without opening the tool: what came in, what the automation decided, and what it wrote out. That is a timestamp, a run identifier, the source record, the branch taken, the destination record, and the outcome. Everything else is optional.

Most automations I inherit log nothing. They work, so nobody thought about the day they stop working, and on that day the only evidence is whatever the platform happens to have kept. That is a bad position to negotiate from when a client is asking why forty leads did not reach their CRM.

I have been running automations in production for years now, including an Airtable and WhaleSync pipeline for Ajust that has delivered more than twenty five thousand cases, and a HubSpot integration for Kismet Health that routes through Zapier. The logging habit came from the second time I had to reconstruct a week of missing records by hand.

Why is the platform's own run history not enough?

Because it expires and it truncates. Zapier's own documentation states that Zapier can only guarantee a maximum of sixty days of Zap run data in your Zap history and will display up to ten thousand runs. That is generous for debugging yesterday and useless for reconstructing a quarter.

The deeper problem is not duration, it is shape. Platform history is organised around the automation, not around the record. When a client asks what happened to a specific lead, you want to search by that lead's email address and see every step it touched. Run history makes you search by time and scroll, which is fine for one incident and impossible for a pattern.

The third gap is cross tool. A real workflow usually spans two or three products. A form fills in Webflow, a row lands in Airtable, a contact is created in HubSpot. Each tool has its own history with its own retention and its own idea of an identifier. Nothing joins them unless you write the join yourself, which is what a log is.

What belongs in a single log line?

A log line should carry the time the run started, a unique run identifier, the identifier of the record that triggered it, the name and version of the automation, the branch it took, the identifier of whatever it created or updated, and a plain outcome value such as created, updated, skipped, or failed.

The branch field is the one people leave out and regret. Automations grow conditions, and a condition is a decision. If you only log that a run succeeded, you cannot tell the difference between a run that correctly skipped a record and a run that skipped it because a field was empty when it should not have been. Both look like success and only one is.

The outcome value should be a short fixed vocabulary that you actually enforce, not free text. Free text outcomes turn into a hundred variations of the same message within a year, and then you cannot count them. Counting them is the whole point, because a count is how you notice that skipped runs went from two a week to sixty.

What should you never put in a log?

Never log secrets, full payloads, or personal data you do not need. That means no API keys, no access tokens, no complete request bodies, and no health or financial detail. Log the identifier of the record, not the contents of the record, and fetch the contents from the source system when you actually need them.

The reasoning is boring and important. A log is usually the least protected store in a workflow, because it gets created quickly and reviewed rarely. It ends up in a spreadsheet that gets shared, or a table that a contractor has access to. Anything you put in it should be safe in all of those places, and a full payload is not.

There is a practical benefit too. Identifier only logs stay small, stay fast to search, and stay readable. Full payload logs become multi megabyte rows that nobody scrolls through, which means they provide the feeling of observability without any of the use. I would rather have six fields I read than sixty I ignore.

Where should the log actually live?

Put it somewhere you can query without permission from anyone, and somewhere separate from the systems it describes. For most small teams that means a dedicated Airtable base or a single wide sheet. For anything with volume, a proper database. The requirement is queryability, not sophistication.

Separation matters more than the technology choice. If your log lives inside the same Airtable base that the automation writes records to, then a bad run that corrupts the base can corrupt the evidence of what it did. I keep logging in its own base with its own access rules, which also makes it safe to give a client read access to the log without giving them the working data.

Whatever you pick, decide the retention deliberately rather than by accident. I keep detailed run logs for ninety days and a rolled up daily summary indefinitely, because the summary is what answers the question of whether things are getting worse and it costs almost nothing to keep. The detail is what answers the question of what happened on Tuesday, and Tuesday stops mattering fairly quickly.

How do you log a failure that never ran at all?

You cannot, which is why a log needs a companion. A run that does not happen produces no line, so silence in a log reads identically to health. The fix is a scheduled check that expects a minimum number of runs in a window and raises an alarm when the count comes in under it.

This is the failure mode that has cost my clients the most. A trigger quietly disconnects after a credential expires, and the automation does not error, it simply stops being invoked. Every dashboard looks green because green is the absence of red, and nobody is counting. Two weeks later somebody notices that the pipeline looks thin.

The check itself is trivial. Once a day, count yesterday's runs, compare against a floor you set from normal volume, and send yourself a message when it is lower. I have written about the related decision of what an automation should do when it hits an error in whether an automation should retry or stop and ask, and the two habits together cover most of what goes wrong.

How much logging is too much?

You have too much when nobody reads it. The practical test is whether you can look at a week of logs in under five minutes and come away with an opinion. If the answer is no, you are logging for the feeling of diligence rather than for use, and the volume is actively hiding the signal.

The common overshoot is logging every step of a multi step automation as its own line. That feels thorough and produces eight lines for one meaningful event, which means your counts are wrong and your searches are noisy. One line per run, with the branch recorded, tells you almost everything the eight lines would have. Add step level detail only for the one step that keeps failing.

The other overshoot is alerting on everything you log. A log is a record, an alert is an interruption, and conflating them trains you to ignore both. I alert on failures and on volume floors. Everything else I look at on a schedule, which is a different and much calmer relationship with the same data.

How do you use a log when something breaks at an awkward hour?

You start from the record, not the automation. Take the identifier the client gave you, search the log for it, and read the line. The branch field tells you what the automation decided, the outcome tells you what it did, and the destination identifier tells you where to go and look. That is usually the whole investigation.

When the record is not in the log at all, you have learned something more useful than any error message. The automation never saw it, which moves the problem upstream to the trigger, the form, or the filter. Half the automation incidents I get called about are not automation incidents, and the log is what proves that in two minutes instead of two hours.

The reason this works under pressure is that it requires no thinking. A written lookup path that a tired person can follow is worth more than a clever dashboard nobody remembers how to read. I keep the lookup path in the same document as the automation's naming and ownership notes, which I described in naming conventions that keep automations maintainable.

What should you do next?

Pick your single most important automation and give it one log line per run, with seven fields and a fixed outcome vocabulary. Do not retrofit the whole stack. One automation logged properly teaches you what the fields should be, and the second one takes twenty minutes because you already know.

Then add the volume floor check before you add anything else. It is the cheapest piece of monitoring you will ever build and it catches the failure that logs alone cannot see. Everything after those two moves is refinement rather than foundation.

If you have automations running in production and no honest answer to the question of what happened last Tuesday, I am happy to look at what you have and tell you where the gaps are. Reach out and tell me what your stack looks like.