Why an automation can say "completed" and still lose your data

An automation can report "completed" while the work is wrong, because nearly every tool checks that the process finished and almost none check that the result is correct. It happened to my own backup: it copied my database without a single error, and when I compared it against the original, one table was missing 22 of its 316 records. This isn't a small-business problem. In Kaseya's 2025 report, 60% of the IT professionals surveyed believed they could recover in under a day, and only 35% actually did.

Key points

• "It finished" and "it's right" are different questions. Most tools only answer the first.
• Silent failures leave no errors behind: the status says OK, the file opens, the size looks normal.
• You catch them by comparing what went in with what came out. No code required.

What a silent failure is

A silent failure is when an automation finishes, reports success, and delivers an incomplete or wrong result with no alert. It's worse than a crash. When something crashes, someone notices that day. When something fails quietly, you find out weeks later, usually from a customer.

The confusion comes from what "success" means to a tool. For Zapier, Make or a scheduled script, success means every step ran without throwing an error. It doesn't mean the email arrived, the record was saved or the copy is complete. The gap between "it ran" and "it worked" is where data goes missing.

What makes it harder to spot is that many of these failures show up in automations that had been working for months. A field gets renamed, a token expires, an address lands on a bounce list. Nobody touched the automation, so nobody suspects it.

The case: my backup said it worked

I run my studio with a few internal tools I built. One stores its data in SQLite, a database that lives in a single file. Before changing how that tool stored its data, I wanted a backup, and there was already a function for it: it copied the database file to another folder.

The copy finished with no errors and a plausible size. I could have trusted it right there. Instead, I compared six tables in the copy against the original. Five matched row for row. The messages table didn't: 316 in the original, 294 in the copy.

The reason is how SQLite works in WAL mode (write-ahead logging). New changes don't go straight into the main file. In the words of the SQLite documentation, "the original content is preserved in the database file and the changes are appended into a separate WAL file." Later, in a step called a checkpoint, those changes move into the main file.

When I measured, the WAL file held about 2.3 MB of changes that hadn't moved yet. My backup copied the main file and left the other one behind. The documentation warns about exactly this: "If a database file is separated from its WAL file, then transactions that were previously committed to the database might be lost." When I later wrote a test to reproduce the problem, the old copy didn't even contain a table the test had just created.

The fix had four parts:

1. Copy through the database, not the file. SQLite's VACUUM INTO command, per its documentation, produces "a consistent snapshot of the original database," pending changes included.
2. Write a test that reproduced the missing rows first, and confirm it failed against the old code. A test that has never failed proves nothing.
3. Have every backup run an integrity check and count the rows in each table, so the copy gets compared with the original instead of trusted on sight.
4. Keep two copies on two different drives, every Sunday, on a scheduled task.

One thing I chose not to automate: deleting. Old backups never get removed on their own. A person makes that call.

Five ways an automation reports success without doing the work

My case was technical, but the same pattern shows up in tools any business uses. These five come from real cases posted in the Zapier, Make and Shopify communities.

1. A filter stops matching. A Make user documented scenarios that end in "Success" having written nothing. One cause: someone renamed a field at the source, and the filter that let data through stopped matching. The scenario runs, finds nothing that passes, and finishes happy.

2. A search returns zero results. If a step looks up a record and finds none, the next steps run zero times. No error, technically. Nothing happened, in practice.

3. An error handler closes the run as a success. Many tools let you say "if this step fails, keep going." Useful, until nobody checks what got skipped and the run is logged as a success with a missing step inside.

4. The destination rejects quietly. In the Zapier community there's a case of an email step that worked for a year and then kept reporting "successful" while nothing arrived. The recipient's address had ended up on a bounce list. Expired tokens behave the same way: the tool sends, the other side refuses, and the history stays green.

5. Something incomplete gets copied. That's my backup, and also a Shopify store owner whose contact form stopped emailing them after a year. They found out when customers started complaining on social media that nobody answered.

The gap between confidence and reality

The research shows the same thing from the other side: people trust their systems more than their systems deserve.

Kaseya surveyed more than 3,000 IT professionals in 2025: 60% believed they could recover in under a day, and 35% did. Veeam's 2026 report, based on more than 900 IT, security and risk leaders, found that 90% of organizations are confident they can recover from an incident, yet among ransomware victims only 28% fully recovered all affected data. On average they got back 72%.

The same gap appears in Latin America. ESET's 2025 Security Report, covering more than 3,000 people at organizations in over 15 countries in the region, found that 32% admit they have no tools to confirm they haven't been attacked, and that backup is the only widely implemented protection.

Read these numbers with care: almost all of them come from companies with dedicated technical teams. A small business running a form, a booking tool and a cloud backup usually has less oversight, not more, because nobody is assigned to check.

W. Curtis Preston, who has written about backups for decades, puts it in one line: "A backup that fails silently is worse than no backup at all." It's worse because it lets you stop worrying.

How to check your automations without code

Google's Site Reliability Engineering book advises spending "much more effort on catching symptoms than causes." For a business, that means something concrete: don't look at whether the automation says OK. Look at whether the thing it was supposed to do actually happened.

None of these takes more than ten minutes. The hard part is remembering, so put them on your calendar like any other recurring task.

Before trusting a new automation, ask three questions. How would I know if it stopped working? If the answer is "a customer would tell me," you're already late. What does it check besides having run? If nothing, add one comparison. What can it delete or send on its own? That one gets its own section.

What you shouldn't fully automate

Automating the preparation of a task is almost always worth it. Automating the final decision isn't always.

Actions you can't undo should wait for a person to confirm: deleting data, sending money, cancelling an account, messaging your whole customer list. If an automation gets one of those wrong, no later check can fix it.

My backup tool copies, verifies and stores on its own, but never deletes. In another tool I use, the system prepares messages and a person decides which ones go out. It's a little slower, on purpose.

FAQ

Why does an automation say "completed" when it failed?

Because "completed" means every step ran without throwing an error. A filter that lets nothing through, an empty search or a destination that quietly refuses don't throw errors, so the run is logged as a success.

How do I know my contact form is working?

Send yourself a test enquiry, ideally from a different email address, and confirm it arrives. Do it once a month and whenever you change anything on your site or email.

How often should I test a backup?

As often as you'll realistically keep doing it, and always after a significant change to the system it protects. Testing means opening the copy and finding something recent, not just seeing that it exists.

Do Zapier or Make warn me when something goes wrong?

They warn you when a step throws an error. They don't when the result is empty or incomplete, because to the tool that isn't an error. That's why you need a check on the result.

Do I have to stop automating to be safe?

No. Automate the repetitive work and add a check on the result. The only thing I'd always leave to a person is what can't be undone.

To wrap up

A copy isn't a backup until you've opened it, and an automation isn't working until something has compared what it received with what it delivered. If you've automated parts of your business and you're not sure how you'd know when one stops working, that's the first question worth answering. If you'd like a second pair of eyes, you can reach me at sendalogica.com.

Sources

1. SQLite — Write-Ahead Logging https://sqlite.org/wal.html
2. SQLite — VACUUM (VACUUM INTO) https://sqlite.org/lang_vacuum.html
3. Kaseya — State of Backup and Recovery Report 2025, February 6, 2025 https://www.kaseya.com/press-release/kaseya-report-outlines-top-trends-in-backup-and-recovery-in-2025/
4. Veeam — Data Trust and Resilience Report 2026, April 14, 2026 https://www.veeam.com/company/press-release/veeam-report-reveals-a-market-wide-shift-from-recovery-confidence-to-proven-data-resilience-amid-ransomware-threats-and-ai-adoption.html
5. ESET — Security Report 2025 Latin America, July 30, 2025 https://www.welivesecurity.com/es/informes/eset-security-report-2025-ciberseguridad-empresas-latinoamerica/
6. W. Curtis Preston, Backup Central — Backup Systems all Need These 10 Things, December 8, 2025 https://backupcentral.com/backup-systems-all-need-these-10-things/
7. Google — Site Reliability Engineering, chapter 6: Monitoring Distributed Systems https://sre.google/sre-book/monitoring-distributed-systems/
8. Make Community — A scenario can finish "Success" and still have written nothing https://community.make.com/t/a-scenario-can-finish-success-and-still-have-written-nothing-three-ways-it-happens/114177
9. Zapier Community — Send Outbound Email: zap successful but email not received by recipient https://community.zapier.com/troubleshooting-99/send-outbound-email-in-email-by-zapier-zap-successful-but-email-not-received-by-recipient-32654
10. Shopify Community — Contact form no longer sending emails https://community.shopify.com/t/contact-form-no-longer-sending-emails/415874