Two Systems, One Key, and Nothing Happened

This morning one of my own systems almost erased a piece of work and told me everything was fine.

Here is what happened in plain English, because the lesson is not about code. It is about what happens any time two things you built reach into the same drawer.

I run more than one automated writer on this site. They do different jobs. One handles a five lane run. Another handles a four lane run. Both of them write into the same queue table before anything gets published.

To keep a restarted run from posting the same article twice, every row carries what is called an idempotency key. It is just a unique label. Mine are built the same way every time. The word daily, then the date, then the name of the lane. So this morning one system wrote a row labeled daily 2026 09 09 builder.

The other system was scheduled to write a row with that exact same label.

The database rule I use in these runs is ON CONFLICT DO NOTHING. That is standard Postgres behavior for a safe rerun. If a row with that key already exists, skip it quietly and keep going. It exists so a job that dies halfway through does not duplicate everything it already finished.

It worked exactly as designed. That is the problem.

DO NOTHING does not mean nothing was lost. It means nothing was said.

If I had not gone looking at the existing keys before writing, today's piece would have been written, handed to the database, quietly dropped on the floor, and reported as a clean run. Four articles planned. Three published. A report that says everything went fine.

That is the worst kind of failure. Not the loud one. The polite one.

Three fixes. They apply to anything you automate, not just a website.

One. Put your name on the key

The label should say who wrote it, not just what day it is. Not daily, date, lane. Something closer to voice run, date, lane. Two systems, two names, no collision possible.

This is the same reason none of your files are named document.

Two. Make the silence loud

If your write can quietly do nothing, then check afterward whether it actually did something. Count what you meant to create. Count what landed. If those two numbers disagree, the run is not clean, no matter what the last step reports.

Every automation should finish by verifying its own work instead of assuming it.

Three. Know every writer touching the shared table

I built both of these systems and I still did not have a single list of everything that writes into that queue. That is the actual root cause. The key collision was only where it surfaced.

Now here is why I am writing this up instead of just fixing it and moving on.

This is the same failure I find in businesses that have nothing to do with software.

Two people each think the other one called the lead back. The form on the website and the form on the landing page both write into the same spreadsheet and one silently overwrites the other. The receptionist takes a message, the answering service takes the same message, and the customer gets called twice or never. One tool posts to your page, a second tool posts to the same page, and one of them fails without telling anybody.

Nothing errors. Nothing alarms. The work just quietly does not happen, and everybody reports a good day.

You do not find that by watching for errors. There are no errors.

You find it by counting.

Count what should have gone out. Count what actually went out. When those two numbers do not match, go looking, because something inside your business is doing nothing very politely.

If you want help finding where your own systems are quietly dropping work, that is most of what I do. The LeadFlow Pro is where that work lives.