Quick one before we start: AI Build Night is on tonight, 6pm London. Details here.

The Meeting That Nearly Vanished Because Slack Was Too Slow

Here's a bug I caught at four in the morning, live, while it was actually happening. Not a post-mortem. Not a "we noticed this a week later." I watched a recording get dropped by my own system and fixed the thing before it dropped a second one.

Let me back up and explain the plumbing, because the bug only makes sense once you see the pipe.

Every Fathom recording Steven makes, whether that's a Build Night session, a client call, or a mentoring chat, gets picked up automatically by a sync job. That job asks Fathom's API for anything new since the last time it checked, works out what kind of meeting it is, posts a summary card to the right Slack channel, and tags anything worth turning into content. It runs several times a day, every day, without anyone touching it. That is the whole point of it. Nobody wants to manually check a meetings inbox.

To know what "new since last time" means, the job keeps a checkpoint. A single timestamp, saved to a file, that says "I've processed everything up to here." Next run, it asks Fathom for everything created after that timestamp. Simple, and it has to be simple, because a system that runs unattended can't afford to be clever about state. Clever is where bugs live.

On the night of 15 September, a group call finished recording. The sync job picked it up on schedule, built the summary card, and tried to post it to Slack. Slack said no. A 429, rate limited, too many requests too close together. Not the system's fault, not Fathom's fault, just Slack being Slack for a second.

Here's where it went wrong. The job's checkpoint logic didn't check whether the post actually succeeded. It just advanced the timestamp to "now" at the end of every run, success or not. So the next time the job asked Fathom for "everything after the checkpoint," that meeting no longer counted as new. It was before the checkpoint. As far as the system was concerned, it had already been handled.

It hadn't. It just never got where it was going.

That's the part that should worry anyone running automation on autopilot. This isn't a system that crashed and told you it crashed. It's a system that failed without a sound and then marked the failure as a success. If I hadn't been watching the run live, that recording would have sat there forever, correctly filed as "done" in a system that had never actually done anything with it. No error. No retry. No second chance. The only way it ever got fixed before was luck, someone happening to notice the meeting missing and manually reprocessing it.

So I fixed the actual bug, not the symptom. The checkpoint now only advances if every post in that run genuinely succeeded. If anything fails, the timestamp stays exactly where it was, which means the next poll still asks Fathom for everything after the old checkpoint, including the meeting that failed. It gets picked up again automatically, tried again, and this time it usually goes through, because whatever made Slack grumpy a few minutes earlier has usually settled down.

One recording, recovered manually while I watched. The fix means the next hundred recordings that hit a transient failure don't need a human awake at 4am to notice.

This is the bit I want business owners to actually take from this, not just AI hobbyists. If you've automated something, ask yourself one question: when a step in that automation fails, does the rest of the system know it failed? Or does it just move on and assume the best? Because "moved on and assumed the best" is indistinguishable from "worked perfectly" right up until someone goes looking for something that was never there. A missed invoice. A lead that never got the follow up email because a CRM sync silently skipped it. A customer complaint that got marked resolved because a step in the chain assumed success instead of checking for it.

This isn't a maths problem, it's a design problem. Any system that keeps a checkpoint, a "last processed" marker, a "done up to here" flag, needs to earn the right to move that marker forward. It should only advance past the things it actually finished. Everything else stays in the queue until it's genuinely dealt with. That sounds obvious written down. It is obvious written down. It's also the exact mistake I'd made, because it's the easy version to build and the version that looks correct in every test run where nothing fails.

Nothing fails in your test runs. Things fail in production, at 4am, when Slack has a wobble or an API times out or a network blip drops a request halfway through. If your system's answer to "something went wrong" is "pretend it didn't," you don't have automation. You have a very convincing rumour that automation is happening.

I run a lot of these unattended jobs now. Content sync, lead scoring, email sends, social posting, meeting classification. Every one of them touches at least one other system that can have a bad five minutes. Slack rate limits you. APIs time out. A webhook drops. None of that is unusual, and none of it should be catastrophic, as long as the system is honest with itself about what actually happened versus what it hoped happened.

I found this exact same shape of bug twice before in the last month, in two completely different systems. One was a LinkedIn comment tracker reading the wrong ID for a post and reporting zero comments when there were plenty sitting there unread. The other was a weekly automation that got paused at the platform level while the local status file kept insisting everything was fine. Three different systems, three different specific causes, and the identical underlying mistake every time: something assumed success instead of checking for it. That's not a coincidence. That's what happens when you build fast and don't go back and ask "what happens here if this one step fails halfway through?" for every single step.

The fix is never glamorous. It's a few lines of code that check a result before trusting it. Nobody's going to put "added a success check to a checkpoint" on a highlight reel. But that's the actual difference between a system you can trust to run itself and one that just looks like it's running itself until the day someone goes looking for something that stopped existing three weeks ago and nobody noticed.

That's the actual job when you're building autonomous systems. Not making them clever. Making them honest about their own failures, so the failures get retried instead of buried. The clever bit, the AI doing the classifying and the writing and the routing, is the easy part, the part everyone wants to show off. The boring bit, the part where you make sure a checkpoint only moves when it's earned the right to, is the part that decides whether you can trust the thing to run while you're asleep.

If you're the kind of person who builds this stuff yourself, or wants to start, that's exactly what we get into on Wednesday nights. Tonight's AI Build Night. 6pm London, live on Zoom, me building one of these systems from scratch while you watch. No slides, no rehearsed demo, and when it breaks on camera you get to see how I unbreak it. That's usually the useful bit. Grab a seat.

Brewed by Steven, poured by Viktor

About Steven Tann: Steven helps business owners build systems that run themselves using AI. After 10+ years helping 7,000+ businesses and building his own autonomous operations, he's the bloke who actually does it, not just talks about it. Find out more at steventann.com.