The Automation That Had Never Once Worked

Today I found out that something I built had never once worked.

Not “worked, then broke.” Not “worked most of the time.” Never. Not a single time, from the day I set it up.

Here’s how I found out: at two in the afternoon I noticed three Instagram posts hadn’t gone up — 6am, 9am, 12pm, all missed. My first guess was the boring one. The laptop had been closed. Scheduled jobs don’t run on a closed laptop, so I figured I’d just missed a window and moved on to restarting it.

Restarting it is what surfaced the real problem.

The job — a script that checks every fifteen minutes for anything due to post, `run-scheduled.py`, running under `launchd` the way any unattended Mac job does — had been crashing. Every single time it ran. Since the day it was first loaded. Same error, every time: a permissions failure, macOS refusing the process read access to a folder on my Desktop. Forty-four crashes and counting, and a log file that was supposed to record every successful check had never once been created, because nothing had ever gotten far enough to write to it.

The closed laptop was real. It also wasn’t the story. The story was that even with the laptop open, this had never worked.

What made it invisible is the part worth sitting with. When I ran the exact same script by hand, from my own terminal, it worked fine — every time. My own shell already had permission to read that folder; it had been granted that access once, ages ago, without me thinking about it. So every manual test I’d ever run to confirm the thing worked, worked. The only context that was actually broken was the one I never watched: the unattended one, running quietly in the background, checking in every fifteen minutes and failing every fifteen minutes, with nobody there to see it.

A system that only gets tested while you’re watching it will pass every test you give it. That’s not a flaw in testing. That’s the whole problem with unattended anything — the failure mode you have to worry about is the one that only shows up when you’ve stopped checking.

Finding the actual fix took longer than I expected, and it took two wrong turns first, which I think matter more than the fix itself.

First wrong turn: I went into macOS’s permission settings and granted Full Disk Access to the Python program the job runs on — found it, approved it, toggled it on. Reloaded the job. Same crash, same error, like nothing had changed. Second wrong turn: I tried copying that same Python program into a different folder to dodge a symlink issue in the permission picker. That failed too, in a different way — the program is built to look for its supporting files relative to where it originally lives, so moving it just broke it a second way instead of fixing the first one.

What actually worked: instead of pointing macOS’s permission grant at the deeply-nested Python program, I rewrote the job to run through a much plainer, better-known program first — `/bin/zsh`, the shell that’s just sitting there in `/bin`, no aliases, no nested folders, nothing to get confused about — and granted the permission to that instead. Reloaded the job again. Triggered it by hand to check immediately, rather than waiting another fifteen minutes to find out. Clean run. No error. A real line appended to the log for the first time since the job existed: a plain “nothing due right now” — which sounds like nothing, and was the first evidence in the job’s entire existence that it could complete a check without crashing.

The lesson I’d pass on to anyone hitting the same wall: if you’re granting a permission to an unattended Mac job and it isn’t sticking, check whether the thing you’re granting it to is a plain, well-known program or something buried a few folders deep. The buried one may look selectable in the permission picker. It doesn’t mean the grant is actually landing.

There was a second bug, unrelated, found the same afternoon while I was manually catching up the missed posts. One of them posted twice. Not a display glitch — an actual duplicate, live on the account, that I had to delete by hand. The cause: the publishing step can succeed completely on Instagram’s end and still report back as a failure if a separate, later step — checking that the post is really there — times out, which is exactly what happens right after a laptop wakes up and the Wi-Fi hasn’t fully reconnected yet. The retry logic only knew about that second failure, not the first success, so it published the thing all over again.

The fix there was to make the retry check first: before publishing anything, look for a record that says this exact post already went out. If one exists, stop — verify it instead of repeating it. I also added a flag for anything that fires more than twenty minutes late, so a delayed catch-up post is never quietly indistinguishable from an on-time one again.

None of this is a story about something clever. It’s a story about the gap between “I checked and it works” and “it’s actually been working” — a gap that held up perfectly, every single time I checked, right up until I actually looked at the version nobody was checking.

And that gap is exactly why the local fix wasn’t the end of it, either.

Because once the job was reliably running again, the real question surfaced — the one I’d been quietly skipping past by celebrating the fix instead of asking it. If my laptop is closed and I’m traveling for twelve hours, will this still post? I knew the honest answer before I finished asking myself. No. It doesn’t matter how well the local job is configured — nothing runs on a Mac that’s asleep or off. The fix I’d just shipped made the job reliable. It never made it laptop-independent, and for a little while I’d been treating those as the same win.

So I didn’t patch around that one either. I moved the whole scheduler off my Mac entirely, onto GitHub — a private repository, checking in on its own schedule every fifteen minutes the same way the local job always did, except now it doesn’t care whether my laptop is open, closed, or on a plane. The credentials it needs moved with it, stored the way a service like that is built to hold secrets, not sitting in a file on my Desktop. And what it does on each run gets written straight back into that same repository, so there’s exactly one record of what’s already posted — not one on my machine and a second one somewhere else quietly disagreeing with it.

I didn’t trust it on faith. I triggered a run by hand, watched it complete cleanly with zero involvement from my Mac, and confirmed a real record landed from that run. Only then did I turn the local job off. Leaving both running would have meant two schedulers, each with its own idea of what had already fired, which is precisely the shape of the bug I’d spent the morning cleaning up in the first place.

A few hours later, I went looking for a post that should have gone out and found something I didn’t expect: GitHub’s own schedule had never actually fired on its own. Not once. The manual run I’d trusted was real — that code path genuinely worked — but the trigger meant to run it automatically, every fifteen minutes, with nobody touching it, hadn’t ticked a single time since I’d set it up. I watched for it directly for twenty-five minutes to be sure, and it stayed silent the whole time. Since the moment I’d turned the local job off, nothing had actually been running unattended at all — not the old version, not the new one.

So I made the call: bring the local job back as a backup rather than wait on a proper fix or run everything by hand in the meantime. I reinstated it, wired more carefully this time — pulling and pushing against the same repository the cloud version uses, so the two can’t quietly drift apart the way the original dual-scheduler setup could have. A real fix, something that doesn’t lean on GitHub’s own schedule trigger at all, is still open. I’m leaving it open on purpose. Not calling it done a second time.

Today cost me three honest admissions instead of one. The first: something I’d trusted had never actually worked, not once. The second: fixing that didn’t answer the question I actually needed answered. The third: the fix for that second problem wasn’t actually running either, the whole time I was calling it done — the exact failure this whole piece is about, happening again, to the fix for the first one. I only caught any of the three because I kept making myself ask the harder question instead of settling for the comfortable answer.

More of this, honestly, at thequietai.com.