Why your build-in-public GitHub bot stopped tweeting

A good chunk of the open-source "turn my commits into tweets" scripts floating around GitHub work the same way: a scheduled GitHub Action, running on a cron trigger, that checks your recent commits and posts a summary to X. They're genuinely useful when they're running - and they have a habit of quietly dying weeks or months later without any obvious error, which is usually more frustrating than if they'd just failed loudly. If yours has gone silent, it's almost certainly one of a small number of known causes. Here's how to check each one, in the order most likely to be your actual problem.

1. GitHub disabled your scheduled workflow (the most common cause)

GitHub automatically disables scheduled workflows - the ones triggered by a cron entry rather than a push or PR - after 60 days with no activity in the repository. "Activity" here means commits, PRs, or other repo events, not the workflow running itself. If you've been quiet on a side project for two months, the scheduled job that was supposed to tweet about it silently turns itself off, which is a genuinely unhelpful bit of irony: the bot exists specifically for the weeks you're busy building and not thinking about marketing, and that's exactly when GitHub shuts it down.

To check: go to your repo's Actions tab, find the workflow, and look for a banner saying it's been disabled due to inactivity. If you see it, you can manually re-enable it from that same page - but it will disable itself again after another 60 quiet days, so this isn't a permanent fix, just a recurring chore.

2. The X API moved out from under your library

X's main API surface is now v2, but a lot of older bot scripts - especially ones built a few years back, or using older community libraries - still call the v1.1 endpoints. When those endpoints get deprecated, restricted, or simply behave differently, scripts that worked fine for a long time start failing with authentication or permission errors that look unrelated to the actual cause.

To check: look at the failed workflow run's logs for 401 or 403 errors, or any message mentioning an API version or deprecated endpoint. If your script depends on a library that hasn't been updated recently, that's the first thing to look at.

3. Cron drift and timing issues

GitHub Actions scheduled runs aren't guaranteed to fire at the exact minute you specify - during periods of high load across GitHub's infrastructure, scheduled runs have been known to drift by 30 to 60 minutes or more. For a daily "tweet your commits" bot this is usually harmless; for anything trying to post at a specific time of day, it can mean posts land hours later than intended, or occasionally get skipped if the queue backs up badly enough.

4. Private repo minute limits

If your bot lives in a private repository, GitHub Actions minutes are metered and capped on free and lower-tier plans; public repositories don't have that same limit. If you've got several scheduled workflows running across private repos, or a workflow with a long-running step, it's worth checking your account's Actions usage to see if you've simply hit a minute cap for the billing period.

Debugging order: what to check first

In practice, check these in this order - it matches how often each one turns out to be the actual cause:

1. Open the Actions tab and confirm the workflow isn't disabled for inactivity.
2. If it ran but failed, read the logs for the failing step and look for a 401/403 or deprecation message.
3. If it's a timing issue rather than a hard failure, check whether the run time has drifted from what you expect.
4. If the repo is private, check your account's Actions minutes usage.

The deeper issue: a DIY bot is a second piece of infrastructure

None of the causes above are exotic - they're normal, documented GitHub and X platform behavior. But that's exactly the problem with a homegrown build-in-public bot: it's a second piece of infrastructure you now maintain, on top of the actual thing you're building. Every quiet week on your main project is also a quiet week for the bot's "activity" clock, which means the tool meant to save you time during busy stretches is the one most likely to need your attention during busy stretches.

This is the exact gap Puentiac is built to close. Connecting a GitHub repo to Puentiac uses GitHub's own push and merged-PR events directly - not a cron job that can silently disable itself after two quiet months - so a push still lands in your queue as a draft whether you touched the repo yesterday or five weeks ago. Connect Claude Code, Codex or Cursor over MCP instead, and drafts come from your actual coding sessions, with no GitHub Actions workflow involved at all. Either way, nothing posts on its own: every draft waits in your queue until you review it and press Post yourself on x.com.

Frequently asked questions

The takeaway

A quiet build-in-public bot almost always has one of four boring, well-documented causes - it's rarely a mystery once you check the Actions tab and the failed run's logs. But fixing it once doesn't mean it stays fixed; the same 60-day clock resets every time your project goes quiet for a stretch, which is exactly when you need the bot working least and want it working most.