All Articles

When Your Automation Lies to You

Brandon Gadoci

Brandon Gadoci

March 10, 2026

I run a content pipeline that connects Claude, n8n, and Notion. Articles go out on gadociconsulting.com, social posts get drafted and scheduled in a Notion database, and n8n workflows fire them to Twitter and LinkedIn on a schedule. The LinkedIn side runs through Zapier. The Twitter side calls the X API directly using OAuth 1.0 credentials.

It had been working reliably for months. Then it stopped, and I didn't know.

What Happened

On February 6, 2026, X officially announced a new pay-per-use pricing model for its developer API, moving away from fixed monthly tiers. Legacy free-tier users were given a one-time credit voucher and migrated automatically. The rollout completed around February 28. After that, every POST /2/tweets call on an unfunded free-tier app started returning a 503 error.

The X Developer Community forums filled up immediately with developers reporting the same thing: scripts that had worked fine through February 27 failing consistently starting February 28. The n8n community saw the same pattern. Zidooka covered the change well. It wasn't a bug or an outage. It was a deliberate policy change with no direct notification to affected app owners.

The LinkedIn workflow kept running fine. My Notion records kept showing "Posted" for both platforms. There were no error alerts. I had no idea anything was wrong.

Why It Was Silent

When the 503s started coming back, the n8n HTTP Request node failed, but the workflow had no logic to check the response before updating Notion. Every post that attempted to fire got marked "Posted" regardless of whether anything had actually gone out.

I only caught it about ten days in, when I pulled up the actual X profile and scrolled through the feed. The last programmatic post was February 27. Three posts after that, all marked "Posted" in Notion, had never appeared anywhere. One of them I had already covered manually with a tweet I wrote directly from my phone, with completely different copy than what was in the database.

Using Claude to Figure Out What Was Going On

When I started investigating, I didn't know whether this was a problem specific to my setup or something broader. That's where Claude became useful in a different way than I normally use it.

I described what I was seeing: LinkedIn working, Twitter not, Notion records showing success, no visible errors in n8n. Claude searched for context I didn't have, surfaced the X API pricing change, found the developer community threads showing the same February 28 pattern across many apps, and connected the timing to what I was experiencing. What had felt like an isolated, mysterious failure turned out to be a platform-wide change that hit thousands of developers at the same time.

That context mattered. Without it I would have spent a lot of time looking in the wrong places. The same tool I used to build the automation helped me understand why it had stopped working, and then walked me through what needed to change to fix it.

The Fix

Once the cause was clear, the path forward was straightforward. Getting the app onto the new pay-per-use plan through the X Developer Console required regenerating credentials, since the old ones were tied to an app that was no longer authorized to post.

On the n8n side, that meant updating the OAuth credential with the new keys and re-authorizing the connection. One thing worth knowing if you hit this: if you've set up both OAuth 1.0 and OAuth 2.0 X connections in n8n at any point, you'll have two separate X credentials in your list that look similar. The OAuth 1.0 credential, labeled "X OAuth API," is the one that handles direct posting. Make sure you're updating the right one.

After the credential update and re-authorization, a test post fired immediately.

Cleaning Up

With the pipeline restored, I still had posts in Notion marked "Posted" that had never gone out. Re-firing all of them automatically wasn't the right call. Some were over a week old, and one was time-specific content I'd already posted manually. We reviewed each one, sent what was still relevant, and cleaned up the records to reflect what had actually happened.

What I'd Do Differently

The workflow should check the HTTP response status before updating the Notion record. A 503 should set the status to "Failed," not "Posted." That one change would have surfaced this on day one.

n8n also supports error workflows: a separate workflow that fires when a node fails and can send a Slack message or email. That's now on the list.

And honestly, a periodic check of the actual output, scrolling through the X profile once a week to confirm posts are appearing, is simple enough that there's no good reason not to do it.

The Broader Point

This situation wasn't unique to us. The X API change hit every developer on the legacy free tier on the same day. But the silent failure pattern is a risk in any pipeline where output confirmation lives in a different system than execution logs. Your Notion database said "Posted." Your n8n execution log showed "Success." Your X profile showed nothing. Three sources of truth, two of them wrong.

Building the automation is half the work. Building the visibility layer that tells you when the automation stops working is the other half. It's the half that usually gets skipped because it feels like it can wait.

Now you know what waiting looks like.

Want to Learn More?

Explore our full library of resources or get in touch to discuss how we can help your business.