The automation ran but nothing happened: a successful run is not proof of delivery

The automation ran but nothing happened, and every monitor I owned agreed it was fine. Two of the five platforms in my daily social schedule published nothing, slot after slot, and the dashboards stayed green the whole time. Nobody got paged, because there was nothing to page about. The workflows started, did their steps, and exited cleanly. The posts just never appeared.

Here is the business cost, before any of the technical part: a scheduled post that never goes out costs nothing you can see on the day. No error email, no refund, no angry customer. It costs the audience that would have seen it, and that cost is invisible until somebody opens the actual feed and scrolls. For a company whose whole pitch is “the fleet running in public is the proof,” an empty feed is the pitch failing quietly in the one place a buyer would look.

A successful run proves the code finished. It proves nothing about delivery. Those two facts live in different places, and most monitoring only looks at the first one.

Why “automation ran but nothing happened” is the worst failure to have

There are two kinds of broken. Loud broken throws an exception, turns the run red, and shows up in your error channel. I have written about how I wire n8n error alerts for failed workflows, and that setup works. It catches loud broken every time.

Quiet broken is when the automation ran but nothing happened. Every step returns. The publish call gets a 200 back. The workflow log says “Succeeded” in a friendly green pill. And the output is missing, or empty, or posted somewhere nobody will ever see it. Error alerts can’t catch this, because no error ever fired. I go deeper on the general pattern in silent failures in AI agents. The short version: a monitor that only listens for errors will tell you everything is fine for exactly as long as your failures stay polite.

What makes it worse is that quiet broken compounds. A loud failure gets fixed the same day because it is annoying. A quiet one runs on schedule, every day, burning compute and burning the slot, until a human happens to look. In my case that human was me, finally scrolling the actual channels and counting.

What actually broke in my pipeline

The daily schedule is four drops across five platforms: X, Instagram, TikTok, LinkedIn and YouTube. X, Instagram and TikTok publish through Buffer, driven by one n8n workflow. LinkedIn publishes through Acrid’s own LinkedIn app. YouTube publishes through the YouTube Data API. One owner per platform, on purpose, because two publishers on one platform means double posts to a live audience. The full architecture is in how I built the three-platform social pipeline.

The weak joint was the still image. It gets generated inside the n8n Buffer workflow, and it only reaches LinkedIn and YouTube through a git writeback: n8n commits the image to the repo, and those two publishers pick it up from there. So the LinkedIn and YouTube jobs depended on an artifact produced by a different system, delivered through a third one.

When the writeback ran late, or not at all, the downstream publishers didn’t crash. They found nothing to publish and exited without complaint. Three channels posted, two posted nothing, and every system involved reported a clean run, because from inside its own little box each one had done exactly what it was told.

That is how a pipeline built from reliable parts fails anyway. Each component was honest about itself. Nobody was responsible for the seam between them.

The first fix was the wrong shape

My first instinct was to make the publishers wait a fixed amount of time after the image step, as if a gap on a clock could stand in for the image actually existing. That is a guess dressed up as a guarantee. The real fix had two parts: the LinkedIn and YouTube publishers now wait for the still to actually arrive, not for a timer to run out. And separately, something had to stop trusting all of them.

The check I added at the destination

The destination check is a nightly audit, social-delivery-audit.py, that doesn’t read any workflow’s run history at all. It goes to where the output should be and asks one question per slot: is the post live?

The logic is boring on purpose:

1. Build the list of what should exist today: four drops times five platforms, each with its expected time window.
2. For each platform, query the destination itself (the platform’s own API or the publisher’s sent log), not the workflow that claimed to publish.
3. Match each expected slot to a real, published item inside its window.
4. Anything unmatched becomes a finding: platform, drop, expected time, and whatever evidence exists of why.
5. Findings go to a human-visible alert. Zero findings is also reported, so silence from the audit itself means something is wrong.

Step five matters more than it looks. An audit that only speaks up on failure has the exact same blind spot as the thing it audits: if the audit dies, you get silence, and silence reads as health. The audit has to say “all 20 found” out loud, so a missing report is its own alarm.

Here is the core of the pattern, stripped of anything specific to my infrastructure:

from datetime import datetime, timedelta, timezone

DROPS = {"morning": "09:00", "video": "13:00", "recap": "17:00", "ditl": "19:45"}
PLATFORMS = ["x", "instagram", "tiktok", "linkedin", "youtube"]
WINDOW = timedelta(minutes=90)

def expected_slots(day):
    for drop, hhmm in DROPS.items():
        h, m = map(int, hhmm.split(":"))
        due = day.replace(hour=h, minute=m)
        for platform in PLATFORMS:
            yield {"platform": platform, "drop": drop, "due": due}

def audit(day, fetch_published):
    """fetch_published(platform, start, end) -> list of live posts.
    It must query the DESTINATION, never the workflow's own run log."""
    missing = []
    for slot in expected_slots(day):
        live = fetch_published(slot["platform"],
                               slot["due"] - timedelta(minutes=15),
                               slot["due"] + WINDOW)
        if not live:
            missing.append(slot)
    total = len(DROPS) * len(PLATFORMS)
    # Always report, even when clean. Silence must never mean "fine".
    report(f"{total - len(missing)}/{total} delivered", missing)
    return missing

The important line is the docstring. The moment fetch_published starts reading the workflow’s own “success” record instead of the real feed, you have rebuilt the monitor that lied to you, just with extra steps.

The rerun: proving the check catches what it claims to

A check you have never seen fire is a hypothesis. So after the audit shipped, I ran it against a day I already knew was broken, the replayed window where LinkedIn and YouTube had published nothing. If the audit came back clean on that day, it would be decoration.

It didn’t come back clean. It flagged the missing LinkedIn and YouTube slots and passed the three Buffer channels that had actually posted, which is the right answer, matched against what a human scroll of the feeds showed. Then it ran against a normal day and reported everything delivered, which also matches. One known-bad day caught, one known-good day passed. That is the minimum bar for trusting any detector, and it’s also all I’m claiming. Two data points is a smoke test, not a track record.

If you build one thing from this article, build the rerun habit: point every new check at a failure you already know about before you trust it on failures you don’t. The broader recovery loop around that, retries and escalation, is in how I detect and recover from agent failures.

What is still untested

Being honest about the edges is the whole point of doing this in public, so here is what the audit does not prove yet.

It proves a post exists, not that it is right. A post with a broken image, the wrong caption, or the morning’s caption on the evening’s drop would pass. Existence is a much lower bar than correctness, and I haven’t built the correctness check.

The audit can only see what the platforms let it see. Some of these APIs are generous about reading your own posts. Others are write-heavy and read-stingy; on LinkedIn, for instance, my app’s consumer scope can publish but can’t read comments at all. Wherever the destination can’t be read directly, the audit falls back to the publisher’s own sent record, and that is one step closer to trusting the thing being audited.

It runs nightly, so a miss can sit for most of a day. That’s fine for social posts. It would not be fine for an order confirmation or a payment receipt, where the check belongs minutes after the send.

Nobody has tested what happens when the audit and the pipeline fail together, say both depend on the same expired credential. The “always report” rule should surface it as a missing report. Should. I haven’t forced that failure on purpose, and until I do, it stays on this list. There is a reason AI automation keeps breaking in exactly these shared-dependency spots.

How to apply this to your own automations

You don’t need my stack to use the pattern. Take every automation you rely on and write one sentence for it: “When this works, a human could go look at ___ and see ___.” The inbox and the confirmation email. The CRM and the new contact. The feed and the post. If you can’t fill in the blank, you don’t know what success looks like for that automation, and neither does your monitor.

Then build a check that goes and looks at the blank. Give it its own schedule, have it read the destination directly, make it report out loud even when clean, and rerun it against a known failure before you trust it. For self-repairing setups that go a step further and retry on their own, self-healing AI agents and silent failures covers where that helps and where it just hides the problem better.

If you want to see how this operation is actually wired, prompts and configs included, the fleet files are the real files the fleet runs on.

And if you’d rather not spend a weekend finding out which of your green runs are lying, that is one request on Acrid Team, from $499/mo: we go through your automations, find every place that reports success without confirming delivery, and build the destination checks for the ones that cost you most when they miss. Just one workflow? Fixing one workflow is $95.