Is your automation actually delivering? A 20-minute check
A short operator checklist for confirming that the messages your tools report as sent are actually arriving — and what to do when one of them is not.
Every tool in your stack reports a success state. A campaign shows sent. A webhook returns a green check. An integration says connected.
None of those are claims about whether anything arrived. They are claims about a request being accepted — a much smaller statement. This checklist closes that gap for the handful of flows where a silent failure would actually cost you something.
Budget about twenty minutes. Do it once per meaningful change, and once a quarter regardless.
1. List the flows that would hurt
Not every automation is worth checking. Write down the ones where a quiet failure costs real money or real trust:
- the sequence that runs after someone fills in a form
- the handoff that tells a human a lead is waiting
- anything a customer is expecting because you promised it (a receipt, a confirmation, a notice)
Three to five is plenty. If the list runs to twenty, you are listing features rather than risks.
2. Send one real message through the real path
This is the whole check, and it is unglamorous: trigger the flow for real, to an address you control, and read what arrives.
- Not a preview.
- Not test mode.
- Not "the last send looked fine in the dashboard."
Fill in the actual form. Wait for the actual message. Open it like a recipient would.
3. Read it as a recipient, against these four questions
| Check | What you are looking for |
| ----------------------------- | ------------------------------------------------------------------------------------------------------ |
| Did it arrive at all? | Accepted by the sender is not delivered to a person. Check the inbox, and check spam. |
| Is the content complete? | Merge fields that stayed as {{first_name}}, blocks that rendered blank, a body that is simply empty. |
| Did it arrive in time? | A message that lands five days after its trigger is technically a success and practically useless. |
| Does the reply path work? | Reply to it. If the reply-to address bounces or lands nowhere, the flow is one-way. |
4. When something fails, write down which of the two it was
There are only two shapes, and they need different fixes:
- The request was never accepted — you will usually find an error somewhere. This is the easy case, because something told you.
- The request was accepted and the outcome is still wrong — empty content, no delivery, wrong timing. Nothing told you, and nothing was going to. This is the case this checklist exists for.
Recording which shape you hit is what stops the same failure being re-diagnosed from scratch in six months.
5. Ask your tools the one useful question
When you evaluate a platform, "does it report errors?" is not a useful question — every tool reports errors. Ask instead:
What does your success message actually assert — that you accepted my request, or that a person received my message?
A good vendor answers plainly and tells you which events they can and cannot see. A tool that treats those as the same thing is not lying to you; it is reporting the only thing it knows, and the gap becomes yours to cover.
Why this is worth twenty minutes
A marketing automation failure does not break something visible. It degrades a number that was going to move anyway. If a nurture sequence silently stops firing, you do not see an error — you see slightly fewer replies this month, which is indistinguishable from a slow week, a seasonal dip, or a list that needs refreshing. The first three explanations you reach for are all plausible and all wrong.
Confirming the outcome at the far end, by hand, with your own eyes, is the only check that spans the whole path. Everything else is a report from one end of it.
This checklist is the operator version of "Send succeeded" is not "email arrived", which explains the failure mode and a case where it bit us.