Why Do I Run a Pre-Flight Check Before an Automation Goes Live?

Why do I run a pre-flight check before an automation goes live?

Because most automation failures are not clever bugs. They are skipped basics: a missing owner, an untested empty field, a connection under the wrong account, no alert when it stops. A short pre-flight checklist catches those in ten minutes. Testing harder does not, because you only test what you already thought of.

I studied aeronautical engineering before I ever built a website or a Zap. The idea that stuck with me most was not about wings or engines. It was the checklist. Aviation has long relied on pre-flight checklists, not because pilots forget how to fly, but because skilled people skip obvious steps when they are busy or confident.

Automations fail the same way. The person who built the workflow knows it well, which is exactly why they miss the small thing that breaks it in month three. This is the checklist I run before anything I build touches real customer data.

What is a pre-flight check for an automation?

A pre-flight check is a short, fixed list of questions you answer before an automation is switched on for real. It covers ownership, data, failure handling, monitoring, and rollback. It is not a test plan. It is a final gate that confirms the boring essentials are in place before you trust the system with live work.

The key word is fixed. The list does not change based on how confident I feel about a build. A simple two-step Zap gets the same questions as a multi-tool pipeline. The simple ones finish faster, but they still get asked.

I keep it short on purpose. A checklist with forty items gets skimmed. One with ten or twelve gets read. Every item has to earn its place by catching something real.

Where did the habit come from?

It came from engineering training, where you learn that systems fail at the interfaces and in the conditions nobody designed for. Then it was reinforced by running automations that real people depend on. When an automation serves a client's customers, a quiet failure is not a technical problem. It is someone not getting help.

The clearest example in my work is Ajust. The automations I built there, using Airtable and WhaleSync, sit behind a service that has delivered 25,000+ cases, helped 400,000+ people, and saved 50,000+ hours. At that scale, a skipped check is not an inconvenience. It reaches people. I wrote about that responsibility in what Ajust taught me about automations that serve real people.

The habit applies just as much to smaller builds, like the HubSpot automation I run through Zapier for Kismet Health. Smaller does not mean lower stakes. A lead that never reaches the CRM costs the same whether the Zap has two steps or twenty.

What goes on my pre-flight checklist?

My checklist asks: Who owns this? What is the one outcome it must produce? What happens with empty, duplicate, or strange input? Which account do the connections belong to? Where do errors and silence get reported? How do I turn it off safely? Is there a written note someone else can follow?

Ownership comes first because everything else depends on it. If nobody owns an automation, nobody notices when it breaks. The owner is a named person, not a team, and they know they own it.

The connection question catches a surprising class of problems. An automation connected through a personal account works until that person leaves or changes a password. I check that every connection sits under an account the client controls, and I write down which one.

Why is a checklist better than testing harder?

Testing checks the cases you imagine. A checklist forces you to look at categories you might not imagine on a busy day, like ownership, alerting, and rollback. Both matter. But testing alone rewards the builder's confidence, and confidence is exactly what causes skipped steps. A checklist does not care how sure you feel.

Testing is also biased toward the happy path. You send a clean test record, it flows through, and you feel done. The checklist makes me send an empty one, a duplicate, and one with odd characters. Those are the records real forms produce.

This pairs well with a dry run. I build most automations with a mode that runs the logic without writing to the live system, which I explained in why every automation I build has a dry-run mode. The dry run tests behavior. The checklist confirms readiness.

What does a pre-flight check catch that testing misses?

It catches the missing pieces around the automation rather than inside it: no alert when the trigger goes quiet, no way to pause without breaking data, connections under the wrong account, and no documentation for whoever has to fix it later. None of those show up when you run a test record through.

The alerting gap is the most common. A workflow can pass every test and still fail silently a month later because a form field was renamed. The checklist asks how I will know it stopped, and the answer has to be something concrete, like a daily count with a threshold.

Rollback is the next most common. Before go-live, I want to know how to switch the automation off and what to do with records caught halfway. Deciding that during an incident is much harder than deciding it on a calm afternoon.

When does a checklist get in the way?

A checklist gets in the way when it grows into a ritual nobody reads, or when it is applied to throwaway experiments that never touch real data. The fix is to keep the list short, apply it only at the moment of go-live, and remove any item that has not caught anything in a long time.

I do not run the full list on a prototype I am building to test an idea. I run it when the prototype is about to become something a client relies on. That moment is the gate.

I also revise the list. When something breaks that the checklist should have caught, I add a question. When an item never catches anything, I question whether it belongs. Across 100+ projects for 25+ clients over 6+ years, pruning is what keeps a checklist useful.

How can you build your own pre-flight check?

Start with five questions: who owns it, what outcome proves it works, what happens with bad input, how you will know it stopped, and how you turn it off. Write them in a shared document. Answer them in writing before every go-live, and add a question each time something breaks that the list missed.

Keep the answers with the automation's documentation, not in someone's head. The written answers become the first page of the runbook. When someone else inherits the workflow, they start from a clear picture instead of reverse engineering it.

If you like the engineering angle, I wrote more about how that background shapes my web work in what aeronautical engineering taught me about websites.

What should you do next?

Pick the automation your business would miss most if it stopped tonight. Run the five questions against it today. If any answer is "I am not sure," fix that before you build anything new. Then make the checklist a required step for every future go-live, no matter how small the build.

It costs ten minutes per automation. It saves the week you would otherwise spend cleaning up after a quiet failure.

I build websites and the automations behind them for lead generation, and this checklist shapes how I think about every handover. If you want a second pair of eyes on an automation before it goes live, reach out and let's chat.