The Bug That Wasn't a Networking Bug: A Railway Healthcheck Timeout in Disguise published: false tags: devchallenge, bugsmash

Gbolahan Olawunmi — Tue, 21 Jul 2026 08:37:25 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

supermarket--bot is a WhatsApp order bot written in Go, built for small businesses to take orders directly through WhatsApp. It handles the full order flow — Twilio for messaging, Paystack for live payments, and Cloudinary for product image uploads — plus an admin dashboard for managing orders. I was preparing to demo it to a restaurant client when this bug hit.

Bug Fix or Performance Improvement

The night before a client demo, a routine deploy to Railway stopped going live. Every deploy failed its healthcheck and got killed. No error in the app itself — it just never came up healthy.

I assumed it was a networking/port-binding problem, since that's a classic Docker + Railway gotcha. I spent a few hours chasing that theory before discovering the real bug: my app's boot sequence (connecting to Postgres on cold start) was taking longer than Railway's default 30-second healthcheck window. Railway wasn't rejecting an unreachable app — it was killing a container that hadn't finished booting yet. The fix ended up costing the client demo a two-day delay.

Code

Here's the chronological trail of the debugging session — including the wrong turns, which I think are worth showing:

fix port — changed hardcoded EXPOSE 8080 to EXPOSE $PORT in the Dockerfile
let railway set port — removed EXPOSE entirely, since Dockerfile EXPOSE resolves at build time and can't read Railway's runtime $PORT
add railway config — added explicit railway.toml with healthcheck path
bind to 0.0.0.0 — made the bind address explicit (in hindsight, functionally identical to what was already there)
debug port — added a log line to confirm Railway was injecting $PORT correctly (it was — this ruled out the networking theory entirely)
increase healthcheck timeout — the actual fix: bumped healthcheckTimeout from 30s to 60s
increase timeout — bumped it again to 120s with a retry-on-failure restart policy

Full diff: https://github.com/Gbolaww/supermarket--bot/compare/b30254e~1...c2d09b1

My Improvements

The interesting part of this bug wasn't the fix itself — it was how long I spent solving the wrong problem. Every symptom (deploy fails, healthcheck red, container restarts) looked like a networking issue, and Docker/Railway's EXPOSE and port-binding quirks are common enough that it was a reasonable first guess. But EXPOSE only matters at build time, and Go's ":8080" already binds all interfaces — neither of those theories held up once I added a debug log and saw the port was correct all along.

The real fix was config, not code: my healthcheck window needed to match my app's actual cold-start time, not an assumed one. Once healthcheckTimeout was long enough to cover the real DB-connect duration, the deploy went green on the first try.

Best Use of Sentry

To make this bug visible instead of a mystery next time, I went back and instrumented the exact code path that caused it — the database connection during boot — using sentry-go's distributed tracing. I wrapped the DB connect step in a db.connect span with a child db.ping span, wired Sentry's HTTP middleware across all routes, and added an env-var-controlled artificial delay (SIMULATE_SLOW_BOOT_SECONDS) so I could reproduce the original slow-boot failure on demand.

Instrumentation diff: https://github.com/Gbolaww/supermarket--bot/commit/ec097c0

Reproducing the original failure — a simulated 35-second slow boot, the kind of delay that would blow past a 30s healthcheck window. Sentry flagged it automatically as 296% slower than average:

The healthy boot — same span, no artificial delay, 249.23ms, flagged 97% faster than average:

Side by side, this is exactly the signal that would have caught the original bug in minutes instead of a multi-hour debugging session — a slow-boot span, automatically flagged as anomalous, instead of a healthcheck failure with zero visibility into why.

World Cup Rivalry Bot — AI-Voiced Hype for Every Goal

Gbolahan Olawunmi — Sun, 12 Jul 2026 17:10:46 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built the World Cup Rivalry Bot — a Telegram bot for fans who want their World Cup rivalry to feel alive in their own group chat. You set your team and your rival, and whenever a real goal happens in the tournament, the bot fires back an AI-generated hype line in your team's voice — followed by an imagined clapback from the rival's fans, spoken in a completely different voice.

It works in DMs and in group chats, and each person in a group can root for their own team independently. Since World Cup passion isn't just about scoring — it's about the back-and-forth banter between rival fans — I wanted the bot to capture both sides of that rivalry, not just one team's celebration.

Demo

Try it on Telegram: @worldcup_rivalry_bot

Quick flow:

/start → set your team (e.g. /team Brazil)
/rival Argentina
/autohype → the bot starts watching real World Cup 2026 results for both your team and your rival
/simulate or /simulaterival → instantly demo the celebration pipeline without waiting for a real goal

Code

GitHub: https://github.com/Gbolaww/worldcup-rivalry-bot

How I Built It

The bot is written in Go and runs as a single long-polling process against the Telegram Bot API, deployed on Railway.

A few decisions worth calling out:

Two voices, two AI models working together. Every goal celebration is a two-part exchange: Google's Gemini generates a short hype/trash-talk line for whichever team scored, and a second, different clapback line from the other side's perspective. Each line is converted to speech with ElevenLabs, using two distinct voice IDs — one for the "home" team's fans, one for the rival's — so it genuinely sounds like two different people talking past each other, not one narrator switching sides.
Real tournament data, not mocked results. The bot polls a public, free World Cup 2026 dataset to detect when a tracked team's goal total increases, and auto-fires the celebration — no manual trigger needed once /autohype is on. Since that data isn't second-by-second live, I added /simulate and /simulaterival so the exact same detection-and-celebrate code path can be demoed instantly, without waiting on an actual goal.
Per-user state, not per-chat. Team and rival are tracked by Telegram user ID rather than chat ID, so a group of friends can all use the bot in the same group chat, each rooting for their own team, without stepping on each other's setup.
Getting the AI stack working was its own adventure. Both gemini-1.5-flash and gemini-2.0-flash were already fully deprecated by the time I built this, and ElevenLabs had recently locked free-tier API access to preset "library" voices — so most of Saturday went into just finding which models and voices were actually still available before I could write a single hype line.

Prize Categories

Best Use of Google AI — Gemini generates both the hype line and the rival's comeback line for every goal.
Best Use of ElevenLabs — Two distinct ElevenLabs voices bring each side of the rivalry to life as actual voice notes in the chat.

DEV Community: Gbolahan Olawunmi

The Bug That Wasn't a Networking Bug: A Railway Healthcheck Timeout in Disguise published: false tags: devchallenge, bugsmash

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Best Use of Sentry

World Cup Rivalry Bot — AI-Voiced Hype for Every Goal

What I Built

Demo

Code

How I Built It

Prize Categories