DEV Community

Cover image for My X (Twitter) Weekly Report Bot Showed '0 Followers' for Two Months—The Culprit Was a Non-Existent Account Name in My .env File
oji - building AI in public
oji - building AI in public

Posted on

My X (Twitter) Weekly Report Bot Showed '0 Followers' for Two Months—The Culprit Was a Non-Existent Account Name in My .env File

Hey everyone, it's your friendly neighborhood old man developer here. I'm 38, dabbling in AI agents and automated trading bots on the side, in between my day job.

Today, I want to share a story about one of my self-made bots that's been quietly dead for the past two months. It wasn't a dramatic crash or a visible error; it was far more insidious: it was running "normally" while being completely useless. The cause? An embarrassingly simple mistake.

Weekly Reports of '0 Followers'

I built a simple analytics bot to keep an eye on the KPIs for my X account (@oji_ai_dev). Every Monday morning, it fetches my follower count, tweet count, impressions, and so on, then sends a Slack notification.

At some point, it started spitting out reports like this, week after week:

[Weekly X Report] Followers: 0 / Likes: 0 / Impressions: 0

Initially, I brushed it off. "Ah, maybe the API's acting up," or "I haven't posted much lately, so that makes sense." It's a common side-project pitfall, right? Once something's running, you tend to forget about it. Unless an error notification pops up, you just assume it's "normal."

But after two months of continuous "all zeros" reports, even I started to realize something was off. A quick check of my actual account confirmed I definitely did not have zero followers. My bot was clearly broken.

Logs Were Clean, Code Seemed Fine. What Gives?

Reluctantly, I pulled up the server logs where the bot was running. Not a single error trace. The script was being triggered on time every week, executing, and exiting with status: 200 OK.

Next, I suspected the code. Had the X API spec changed? Was there a bug in the library I was using?

I pulled the code down locally and stepped through it with a debugger, line by line. It was only when I inspected the request payload right before hitting the API that it dawned on me:

"Wait, whose username is that...?"

The target username being passed to the API wasn't my own.

The Culprit Was in .env

The issue wasn't in the code itself, but in my .env file, where I define environment variables.

# Just one wrong line in the .env file

# INCORRECT: Pointing to a non-existent account
X_USERNAME_OJI="@kaito_trend"

# CORRECT: What it should have been
X_USERNAME_OJI="@oji_ai_dev"
Enter fullscreen mode Exit fullscreen mode

I must have copied and pasted an old .env file from another bot I'd built, and completely forgot to update this one line. Facepalm-worthy, I know.

So, why didn't this throw an error? Here's a simplified look at the script's logic:

# Script logic (conceptual)
# This code itself would run without errors

import os

# Load settings from .env
username = os.getenv("X_USERNAME_OJI")

# Hit the API with a non-existent username
# The API returned empty data, not an error
metrics = fetch_x_metrics(username) 

# Since 'metrics' being empty didn't cause an error, 
# the script proceeded to process '0 items'
log_metrics(metrics)
Enter fullscreen mode Exit fullscreen mode

This was the core of my silent failure. The X API, when given a non-existent username, didn't return a 404 Not Found error or anything similar. It simply returned an empty dataset, indicating zero results.

My script, receiving this empty data, interpreted it as "no activity this week" and continued processing. The result? A weekly report that was technically not a lie, but completely meaningless – always showing zero activity.

My monitoring system only checked for process completion, so of course, no alerts were triggered. No errors appeared in the logs. And so, the bot remained "alive but stopped" for over two months.

Lessons Learned from This Failure

While this whole situation is pretty laughable, I think it highlights some common traps in personal development. I've distilled the lessons into three points:

  1. Treat configuration files as part of your code.
    It's standard practice to .gitignore .env files because they contain sensitive information, which often means they're overlooked in code reviews. However, they are crucial "code" that fundamentally changes how your application behaves. Copy-pasting carelessly or relying on assumptions for configuration is extremely risky.

  2. Question the "happy path" of external APIs.
    My assumption was, "If I pass a non-existent ID, it'll obviously return an error." That was a mistake. External API specifications don't always align with your expectations. I should have anticipated cases like "normal response but empty content" and built in some handling—maybe a warning, or even a retry mechanism.

  3. Monitor "output/artifacts" over "process completion."
    Assuming "monitoring OK" just because a process completed successfully is naive. As shown, the process can be fine, but the output can be completely garbage. What really needs monitoring are application-level metrics, like "Is the retrieved follower count suspiciously zero?" We need mechanisms that trigger alerts if, for example, the follower count is zero for N consecutive runs.

When you're running side-project bots, these mundane maintenance and monitoring tasks often get pushed to the back burner. But letting these holes fester could lead to missing truly critical issues down the line. That thought sent a chill down my spine.

So, are your bots still happily chugging along and actually doing their jobs? 😅

Top comments (0)