How Do I Tell a Client That an Automation I Built Broke?

How do I tell a client that an automation I built broke?

Quickly, plainly and before they find out on their own. I send a short message that says what broke, what it affected, what I have already done to stop the damage and when I will update them next. No jargon, no excuses and no waiting for a perfect explanation. Speed and honesty protect the relationship more than any fix.

Every automation eventually breaks. An API changes, a field gets renamed, a vendor has an outage or I miss an edge case. I have delivered more than 100 projects for more than 25 clients over more than six years, and the honest truth is that breakage is part of the work. What separates a good builder from a bad one is not whether things break. It is what happens next.

This is the process I follow. It is not a script. It is a set of habits I have come to trust, and the reasoning behind each one.

Why does the first message matter so much?

The first message sets the story. If the client hears about a failure from me, the story is that their builder caught a problem and is handling it. If they hear it from a sales rep who noticed missing leads, the story is that the builder did not know. The facts can be identical. The trust is not.

That is why I send the first message before I fully understand the cause. Waiting to diagnose feels responsible, but from the client's side, silence looks like either ignorance or hiding. Neither is a good look.

The first message only needs four things: what broke, what it affected, what I have done so far and when I will update them next. If I cannot answer one of those yet, I say so. "I do not know the cause yet, I will update you by 3pm" is a complete and honest message.

What do I say, and what do I avoid?

I describe the impact in the client's terms, not in tool terms. "New demo requests from yesterday afternoon did not reach HubSpot" is useful. "The webhook returned a 401" is not. I avoid blaming vendors, minimizing the impact or promising a fix time I cannot guarantee. The client needs to know what it means for their business.

Blaming the vendor is tempting, especially when it is true. But the client hired me to build something reliable on top of those vendors. If an API changed and my build did not handle it, that is still my problem to own. I can explain the cause later without making it the headline.

Minimizing is the other trap. "Just a small glitch" lands badly if the glitch cost them a day of leads. I would rather describe the impact accurately and let the client decide how serious it is.

What do I do before I write the message?

I stop the damage first if I can. Pausing a broken automation, turning off a step that is writing bad data or switching on a manual fallback usually takes very little time. Then I write the message. A paused automation and a clear update is a much better position than a running failure and a perfect diagnosis.

This is why I build every automation with a way to stop it safely. A kill switch, a clear pause step or a flag that halts writes. I wrote about that habit in how to give an automation a kill switch. When something goes wrong, I want stopping it to be the easy part.

I also check what data was affected. Which records were missed, which were written wrongly and over what window. That list becomes the recovery plan and it goes into the first or second update.

How do I handle the recovery?

I fix the cause, then I repair the data, then I confirm with the client that both are done. The data repair is the part people skip. A fixed automation that leaves yesterday's missing leads missing is only half a fix. I backfill or correct the affected records and tell the client exactly what I changed.

For the fix itself, I prefer the smallest safe change that stops the failure, followed by a proper fix if needed. A quick patch at the end of a long day can create the next incident. I would rather keep the automation paused for an extra hour than rush a change I have not tested.

Then I tell the client it is done, in the same plain language as the first message. What I fixed, what data I repaired and anything they should check on their side.

What goes in the follow-up after the fix?

A short written summary: what happened, why, what I changed so it does not happen the same way again and anything the client should change on their side. I keep it to a page. The goal is not to defend myself. It is to leave the client with a clear record and more confidence in the system than before.

I go into more detail on the structure in what I write in an automation post-mortem. The key part is the "what I changed" section. A post-mortem that explains the cause but changes nothing is just a story.

Sometimes the honest finding is that the client's team caused the break. Someone renamed a field or edited a workflow. I still write it up neutrally, focused on the system. "A field rename broke the mapping, so I added a check that alerts on renamed fields" is more useful than pointing at a person.

Do I charge for fixing something I built?

If the failure was my mistake, I fix it without charging. If it came from an outside change, like a vendor API update or a new requirement, that is maintenance, and I agree how that is handled before the build starts. Being clear about this up front keeps the conversation about the fix, not about the invoice.

I work on fixed-fee pricing, with most projects falling between $1,000 and $10,000, so scope is agreed in advance. That model makes the line clearer. A bug in what I delivered is part of what I delivered. A change in the world around it is new work, and I covered how I think about that split in whether automation maintenance should be priced separately from the build.

The worst outcome is a client wondering whether I am being slow on purpose because I am billing the hours. Clear terms remove that question entirely.

What has this approach taught me?

That clients judge you more on how you handle failure than on whether failure happens. A fast, honest message and a clean recovery usually leave the relationship stronger than before. In my experience, trust comes less from systems that never break and more from how the breaks are handled.

It has also changed how I build. Knowing I will have to explain every failure in plain language pushes me to add monitoring, alerts and safe stopping points from the start. I have automations running in production for clients like Ajust, built on Airtable and WhaleSync, and Kismet Health, connecting HubSpot through Zapier. Running real systems for real teams is what teaches you to plan for the bad day.

The habit that matters most is simple. Tell the client first. Everything else is easier once that is done.

What should you do next?

If you build automations for clients, write your first-message template today: what broke, what it affected, what you have done and when you will update next. Add a safe way to pause every live automation you own. Then agree in writing how fixes and maintenance are handled before your next build starts.

If you are a client, ask your builder how they handle failures before you hire them. The answer tells you more about them than their portfolio does.

If you want an automation partner who will tell you the truth when something breaks, reach out. I build websites and the automations behind them for lead generation, and I would rather earn your trust on a bad day than only on a good one. Let's chat.