DEV Community: Chalom Ellezam

Stop sending every alert to Slack. The 4-channel routing matrix I built after 18 months of being paged at the wrong time.

Chalom Ellezam — Mon, 15 Jun 2026 18:29:37 +0000

Disclosure: I am a senior backend tech lead in Paris and I run Belmo, a small European PaaS. This article mentions Belmo once near the end. Everything else is platform-agnostic.

It is 02:47 on a Tuesday. My phone is silent. Stripe's webhook signature has been failing for two hours, every paid signup is queueing into a retry table that nobody is draining, and the alert sits in a Slack channel I last opened on Friday at 18h. I find out at 09:14 when a customer emails asking why his subscription is "stuck on pending".

That morning I rebuilt my routing. Eighteen months and roughly 4,000 alerts later, the version below is what stuck. None of it is platform-specific. The mistake I made, and that I see in almost every solo founder I review, is treating "alerts" as one thing that goes to one place.

Why piping everything into one channel stops working around month three

When you ship your first MVP, you have maybe five alerts a week. They fit in one Slack channel called #alerts, you open it when you sit at your desk, and life is good. Around month three something changes. You added Sentry, a status check, a cron monitor, a payment-failure log, an LLM cost-spike detector. Now you have 50 alerts a week. Most are noise, a few are urgent, and one of them is the one bleeding money right now.

Slack rewards triage during business hours. After hours it is no better than email, because nobody opens Slack at 23h to "check the alerts channel". Telegram on the other hand pushes notifications past Do Not Disturb if you let it, which is exactly what you want for a P0 and exactly what you do not want for a deploy-finished ping. Email is great for digests and awful for anything time-sensitive. Discord is where your community lives, which means alerts there either get drowned by #general or read by users you did not intend.

So the question is never "which channel is best". It is "which alert belongs in which channel". Every production alert is answering four questions. Does this need to wake me up? Does it need a human in the next five minutes? Is it for the team, or only for me? And is the content sensitive (DB errors with row data, customer emails, Stripe events)?

Once you answer those four, the channel picks itself.

The four channels, evaluated by what they actually do at 03h

I want to be specific, because most "Slack vs Telegram" posts compare features in a vacuum. Here is what each channel actually does to your sleep and your inbox.

Slack. Slack is great for team-facing alerts that need context (a thread, a screenshot, a back-and-forth). It is terrible for waking a single human up. Its mobile notifications respect your phone's Do Not Disturb, which is what 99% of users want, but it means a 03h alert in Slack will not ring your phone unless you specifically configured a high-priority keyword for it. Slack is where your team triages incidents the next morning. It is not where you find out the site is down.

Telegram bot DMs. A Telegram bot that messages you directly (not a group chat, a 1:1 DM with the bot) is the cheapest pager you will ever build. It bypasses DND if you whitelist the contact, the API is one curl away, there is no SaaS bill, and the message lands on your lock screen with a sound. The downside: it is private to you. Anything you want the team to see in the morning has to go elsewhere too.

Discord. Discord is what your community is in, and that is a feature for community-facing alerts (a "new signup" cheer in a founder Slack, a deploy log in a build channel) and a bug for anything else. Webhook posting is one line, but if your alert channel lives in the same server as your users, accidents happen. Use a separate, private Discord server for ops if you go this route.

Email. Email is excellent for one thing: digests. The daily 09h summary, the weekly cost report, the "here are 12 things that happened overnight that you should know about but did not need to act on". It is awful for anything that needs a response in less than four hours, because by then it is already buried under 30 newer emails.

I deliberately leave SMS and PagerDuty off this list. SMS costs money per message and rate-limits at the worst time. PagerDuty is excellent and also overkill for a solo founder with two services. If you are a team of five with on-call rotation, add PagerDuty. Below that, Telegram-as-pager is fine.

The matrix that picks the channel for you

Here is the routing logic I run for every project I ship now. It maps a single severity tag (P0, P1, P2, P3) and an audience flag (me, team, community) to a channel.

Severity	What it means	Audience	Channel
P0	Site down, payments failing, data loss in progress	me	Telegram bot DM (+ optional SMS)
P1	Degraded, urgent, customer-visible within 1h	me	Telegram bot DM
P2	Anomaly, needs eyes today, not bleeding	team	Slack (or private Discord)
P3	FYI, monitoring noise, "we processed 412 jobs"	me	Email digest, daily
P3	Deploy finished, build succeeded, new signup	community/team	Discord or Slack

The thing this matrix forces you to do is tag every alert at the source. You no longer write "if (error) sendToSlack". You write sendAlert({ severity: "P0", audience: "me", message: ... }) and a tiny router decides where it lands. Severity tagging is the unsexy work that pays off the most. It is the same discipline that PagerDuty enforces with their incident levels, but you do not need to pay PagerDuty to enforce it on yourself.

A 30-line router that does all of this

Here is the Node.js version. Python and Go are trivial translations. The thing I want you to see is how short it is. Most founders assume "alert routing" is a project. It is a function.

// alerts.js
const TELEGRAM_TOKEN = process.env.TELEGRAM_BOT_TOKEN;
const TELEGRAM_CHAT_ID = process.env.TELEGRAM_CHAT_ID;
const SLACK_WEBHOOK = process.env.SLACK_WEBHOOK_URL;
const DISCORD_WEBHOOK = process.env.DISCORD_WEBHOOK_URL;

async function sendTelegram(text) {
  await fetch(`https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      chat_id: TELEGRAM_CHAT_ID,
      text,
      parse_mode: "Markdown",
    }),
  });
}

async function sendSlack(text) {
  await fetch(SLACK_WEBHOOK, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ text }),
  });
}

async function sendDiscord(text) {
  await fetch(DISCORD_WEBHOOK, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ content: text }),
  });
}

// Email digest is just an INSERT into a daily_digest table.
// A cron at 09h flushes it. No external service needed.
async function queueEmailDigest(text) {
  await db.query(
    "INSERT INTO daily_digest (created_at, body) VALUES (now(), $1)",
    [text]
  );
}

export async function sendAlert({ severity, audience, message }) {
  const prefix = `[${severity}] `;
  const text = prefix + message;

  if (severity === "P0" || severity === "P1") {
    return sendTelegram(text);
  }
  if (severity === "P2") {
    return audience === "team" ? sendSlack(text) : sendTelegram(text);
  }
  if (severity === "P3") {
    if (audience === "community" || audience === "team") {
      return sendDiscord(text);
    }
    return queueEmailDigest(text);
  }
}

Every alert in your code now becomes a single function call with three keys. The router takes care of the rest. The two extra lines of discipline (tagging severity and audience at the call site) are what gives you back your weekend.

The three routing mistakes that cost me real sleep

I do not want this post to read as if I figured this out in a meeting. I figured it out by getting it wrong, three different ways, on three different projects.

Mistake one: routing P0 to Slack because "the team is there". This is the 03h Stripe-webhook story above. The team is there but the team is asleep, and Slack is asleep with them. P0 means "wake one human up", and that human is you. Slack will not. A Telegram bot will.

Mistake two: routing everything to Telegram because "it works". I did this for six weeks after the Stripe incident. By week three I had alert fatigue so badly that I silenced the bot. By week five I missed a real P0 because I had trained myself to ignore the buzz. Alerts have a budget. Demote ruthlessly. If it is not actionable within an hour, it does not go to Telegram.

Mistake three: no dedup window. A failing cron that runs every minute will send you 1,440 identical Telegram messages in a day. The fix is two lines: hash the alert message, look up the hash in Redis or a small sent_alerts table, skip if seen in the last 30 minutes. I added this after the cron that watches my email worker spammed me with 600 messages on a Sunday. The number to remember is 30 minutes: long enough to suppress noise, short enough that a real incident gets a fresh ping if it persists.

What I built around all of this

The reason I think about this so much: I built Belmo's monitoring around exactly this routing instinct. Past clients like BeReal had whole observability teams writing these routers in-house. The smaller clients I review on the side had none of it. Alerts went to one Slack channel, the channel got muted in week six, then a customer complaint became the monitoring system. So I built an AI watcher that reads logs, classifies anomalies into severities (retry loops, token spikes, hot Sentry fingerprints, silent cron failures), and pushes the P0s and P1s straight to a Telegram bot. The free tier never sleeps, which matters specifically because the alerting layer must not be the thing that fails. That is the whole pitch. You do not need Belmo for any of this to work, only a tagging discipline and the 30-line router.

What to do tonight, regardless of which platform you ship on

Seven steps, in order, none of them more than 10 minutes.

Open every place an alert currently fires in your code. Count them. If you do not know the number, that is the first finding.
Add a severity and audience argument to your existing alert function. Default both to safe values (P2, me) so nothing breaks.
For every existing alert, set the severity. Be honest. Most of what you have today is P2 or P3.
Set up the Telegram bot. There is a whole post on this earlier in the series (#4 below). Total time, 5 minutes.
Set up a daily digest table and a 09h cron to email yourself everything that hit P3 during the night. This is the alert-fatigue antidote.
Add the 30-minute dedup window. Two lines and a Redis key, or a row in Postgres with a unique constraint on the hash and an expiry.
Test it. Throw a fake P0 at the router. Make sure your phone buzzes when it should and does not when it should not. Then go to sleep.

What I still get wrong

The matrix above is not right for every team. If you are at five engineers with on-call rotation, PagerDuty pays for itself within a quarter. If your alerts contain customer PII, Telegram bots are not where you want them landing (encrypted email or self-hosted Mattermost is better). And there is a category I have not solved well: alerts that need both wake-up and team triage. Today I send those to Telegram first, then re-post the resolved post-mortem to Slack the next morning. Two steps where one would be better.

The question I want to leave you with: which channel is your phone showing right now, and how many of those alerts have you ignored for more than 48 hours? The answer tells you which severity is in the wrong place. Drop the count in the comments. I will publish whatever pattern I see most often next.

Previous posts in this series

Your indie SaaS has no staging environment. Here is the 30-minute setup (and the 4 production bugs it catches before your users do).

Chalom Ellezam — Mon, 15 Jun 2026 18:27:44 +0000

Disclosure: I am a senior backend tech lead in Paris and I run Belmo, a small European PaaS. This article mentions Belmo once near the end. Everything else works on any platform you ship on.

A founder I review code for shipped a "two-line fix" to her Lovable-built waitlist app at 21h on a Friday. The deploy went green, the homepage rendered. By Saturday morning, none of the new signups were being saved. A migration she had run against her local DB a week earlier had silently been included in the deploy. Production was on schema v3, the code was talking to schema v4.

She did not have a staging environment. Nobody on this kind of project ever does, and yet every solo founder I review eventually loses a weekend to a bug that staging would have caught at the cost of 30 minutes of setup.

This is the version of the setup I now recommend. It does not require Kubernetes, a DevOps hire, or doubling your hosting bill. It catches exactly the kind of bugs that bite when you ship fast and your "test environment" is your laptop with the dev server running.

Why most solo founders skip staging

The canonical advice for staging was written for teams of ten. It assumes a Terraform repo, a CI matrix, separate AWS sub-accounts, and a QA engineer who runs the test suite. Nobody building a solo SaaS in 2026 has any of those. So the founder reads the advice, decides it is not for them, and ships straight from main to production. They are not wrong about the canonical advice. They are wrong about the conclusion.

The 90% version of staging is much lighter. A separate branch, a separate web service running the code on that branch, a separate database, a separate set of secrets, and a separate URL. That is it.

The four bugs staging actually catches

I want to be specific about what staging buys you, because most of what people imagine staging does (catching logic bugs, validating UX) is better done elsewhere. Here is what staging uniquely catches.

One, schema drift. Your local dev DB has a column email_lower that your prod DB does not. You shipped a query that uses it. Production crashes. This happens constantly when a founder runs prisma migrate dev against the local DB and forgets to push the migration. Staging, which runs the same migration command on a real network DB at deploy time, catches it.

Two, environment-variable assumptions. Your code reads process.env.STRIPE_KEY. Locally it lives in .env.local. In production you set it in your platform's UI. In staging, you forgot. Catching this on staging is two minutes. Catching it on prod is a refund email and a tweet.

Three, cold-start and platform-specific failures. Your code works locally because Node never restarts. It breaks in production because the platform recycles containers and your in-memory session store is empty for the first request. Staging on the same platform as prod reproduces the cold-start the second you deploy.

Four, webhook and OAuth callback URL mismatches. Your Stripe webhook is pointed at prod.example.com/webhook. Your local .env has localhost:3000/webhook. Staging exposes whatever URL is hardcoded somewhere it should not be, because the staging app gets a different domain from prod.

If you have ever shipped a fix on Friday and woken up Saturday to one of these, you already paid the staging tax. You just paid it as a bug instead of as 30 minutes of setup.

The 30-minute setup

Five pieces. None of them require a YAML file longer than a haiku.

1. A separate branch (3 minutes)

Create a long-lived staging branch in your repo.

git checkout -b staging
git push -u origin staging

The rule from now on: feature branches merge into staging, you smoke-test on the staging URL, then staging merges into main which deploys to production. Most clients I migrate already think they have this workflow but actually do not, because they merge feature branches directly into main and skip the staging hop.

2. A separate web service (5 minutes)

In your platform of choice (Render, Fly, Railway, Vercel, or anything else that deploys from GitHub), create a second service that deploys from the staging branch. Same repo, same build command, different branch.

If you are on a platform that exposes a YAML config, the diff is one line:

services:
  - name: my-app-staging
    branch: staging
    plan: starter
  - name: my-app-prod
    branch: main
    plan: hobby

If you are on a UI-based platform, you click "New service," select the same repo, change the branch to staging, and you are done.

The cost is usually $0 or close to it. Most platforms have a free or near-free tier for the staging service because staging traffic is tiny. If prod runs on a $19 plan, staging usually runs on a $0 or $7 plan.

3. A separate database (8 minutes)

This is the part founders cut and later regret. The point of staging is to catch schema drift, and schema drift cannot be caught if staging and prod share the same database. They must be separate physical databases.

Spin up a new Postgres instance, same provider as prod, smallest plan. Give it a sensible name like myapp-staging-db. Copy the production schema once:

pg_dump --schema-only $PROD_URL > schema.sql
psql $STAGING_URL < schema.sql

Then seed it with fake data, never with a copy of production. You will be tempted to copy prod because then "it looks real." Do not. Copying prod into staging is how PII leaks happen. Use a seed script.

// scripts/seed-staging.js
import { PrismaClient } from '@prisma/client';
const db = new PrismaClient();

async function main() {
  await db.user.createMany({
    data: [
      { email: 'staging-1@example.test', plan: 'free' },
      { email: 'staging-2@example.test', plan: 'pro' },
    ],
  });
  await db.project.createMany({
    data: [
      { name: 'Test project A', ownerEmail: 'staging-1@example.test' },
    ],
  });
}

main().finally(() => db.$disconnect());

Run it once after creating the staging DB. Done.

4. Separate secrets (7 minutes)

This is where most "staging environments" leak into production. The founder sets up staging, copies the production env vars into the staging service, and now staging is talking to the live Stripe account, the live Resend account, and the live OpenAI key. A confused click on staging sends a real email to a real customer.

The rule is: every external service has a test or sandbox version. Use the sandbox version everywhere on staging.

# Production env vars
STRIPE_SECRET_KEY=sk_live_xxx
RESEND_API_KEY=re_prod_xxx
OPENAI_API_KEY=sk-prod-xxx
DATABASE_URL=postgres://prod...

# Staging env vars
STRIPE_SECRET_KEY=sk_test_xxx
RESEND_API_KEY=re_test_xxx
OPENAI_API_KEY=sk-staging-xxx (separate OpenAI project, $5 monthly cap)
DATABASE_URL=postgres://staging...

For OpenAI specifically, create a second project in your OpenAI dashboard with a $5 hard cap. That way a runaway loop on staging cannot eat your real budget. (See my earlier piece on AI apps silently burning money for what that looks like in production.)

For Stripe, switch the dashboard to test mode and you get a separate set of keys, a separate set of webhooks, and a separate set of customers. The webhooks are the part founders miss. You need to create a separate webhook endpoint in Stripe test mode pointed at your staging URL. Otherwise your staging app silently fails every payment flow and you assume it is your code.

For Resend, Postmark, or whatever transactional email provider you use, send staging mail to a sandbox inbox (Mailtrap, Ethereal Email). The risk is not the provider charge, it is that you accidentally send a "Welcome to MyApp Pro!" email to a real user from a staging test run.

5. A separate URL (2 minutes)

Default to whatever the platform gives you (myapp-staging.platform.app). If you care, add a subdomain like staging.myapp.com. The point is that the staging URL is different enough from prod that no human ever confuses the two. I have seen founders deploy prod from a staging branch by mistake because both URLs lived on adjacent subdomains. Do not be them.

That is it. Five steps, 25 to 35 minutes if you have not done it before, much less if you have.

What changes about your workflow

Before staging: git push origin main, hope for the best.

After staging: push to staging, open staging.myapp.com, click around for two minutes, check the route you changed, verify any new migration ran, then merge staging into main for production.

The extra step is the two-minute smoke test. That is the entire ongoing cost. Once you do this for a week, it becomes muscle memory and you stop noticing the overhead. The compounding return is that the 4 bugs above stop happening. The ratio of "Saturday morning bug-hunts" to "uneventful Saturdays" flips within a month.

A note on CI

I deliberately did not include "set up CI tests" in the 30-minute version. CI is good and you should add it eventually, but it is its own setup project and it is not the part that catches schema drift. The staging hop catches the bugs CI cannot (real-DB migrations, real-platform cold starts, real env-var presence). CI catches the bugs staging does not (logic regressions, type errors). Complementary, not substitutes. Get staging in first, add CI when you have a test suite worth running.

The trap nobody warns you about: stale staging

The most common way a staging environment dies is not deletion, it is decay. Six weeks in, staging stops matching prod. A different Node version. A different env var you only added to prod and forgot to mirror. A migration that ran on prod through a manual psql command but never on staging.

You only find out staging is stale the day a "tested on staging" deploy crashes prod. To prevent this, write a one-page STAGING.md in your repo listing every env var and external integration. Anytime you change one in prod, you change it in staging in the same commit. The README is the source of truth, the platform UI is a reflection.

What I built

I built Belmo, a managed PaaS aimed at solo founders and small teams, in part because I kept setting up the five pieces above manually for clients. On Belmo, a staging service is a checkbox during repo connect: pick which branch is staging, pick which one is prod, get two URLs and two databases. Sandbox env vars and per-environment secrets are first-class, so you do not accidentally copy prod keys into staging. We run from German and Oregon data centers, ISO 27001, GDPR-compliant. The free Starter tier never sleeps, which makes it usable as a staging environment without paying anything.

That is the one mention. The setup above works on Render, Fly, Railway, Vercel, Supabase compute, your own VPS, or anywhere else. Pick the platform you are happiest paying.

What to do tonight, regardless of platform

If you do not have a staging environment, do these in order, and stop whenever you run out of energy.

Create a staging branch in your repo and push it.
On your platform, create a second web service that deploys from the staging branch.
Provision a second database. Do not share it with prod.
Copy your prod env vars into staging, then go down the list and swap every *_live_* or *_prod_* for the corresponding test value. Anything that does not have a test mode (rare, but it happens) gets a separate account.
Write a small seed script. Run it once.
Push a small change (a footer copy edit) to staging first and confirm it deploys cleanly.
Add one sentence to your README: "We deploy via staging → main. Never push to main directly."

The whole loop should fit in an evening. If it does not, stop at step 4 and finish tomorrow. The first four steps already catch three of the four bugs above.

Closing question

The funny thing about staging is that the engineers who most often skip it are the ones who would benefit the most: solo founders shipping fast, vibe-coders launching their first SaaS, agencies running 20 client projects on shoestring infra.

If you have shipped a SaaS in the last 6 months without a staging environment, I am curious what your single worst production-only bug has been. Drop it in the comments. I will probably write the next post on the most common pattern.

Previous posts in this series

Your Postgres will die at 50 concurrent users, not 50,000. Here is the connection pooling guide nobody handed you.

Chalom Ellezam — Mon, 15 Jun 2026 18:23:56 +0000

Disclosure: I am a senior backend tech lead in Paris and I run Belmo, a small European PaaS for solo founders and small teams. This article mentions Belmo once near the end. The fix works on any platform: Render, Fly, Railway, Supabase, your own VPS, whatever you ship on.

You launch on Product Hunt. By 11h Pacific you have 87 people poking around your dashboard. Your error rate starts climbing. Sentry begins shouting PrismaClientInitializationError: Can't reach database server. Your homepage returns blank. You open your Postgres metrics expecting to see CPU pinned at 100%. CPU is at 3%. Memory is barely touched. But pg_stat_activity shows 100 active connections, and you cannot make a new one.

Your database did not run out of compute. It ran out of seats.

This is the single most common production outage I see in indie SaaS, and it almost never gets blamed correctly. Founders blame the framework, the host, "scaling", or the AI model that wrote the code. The real cause is two paragraphs deep in the Postgres docs and nobody reads them until 11h on Product Hunt day.

Why Postgres has a seat limit at all

Every Postgres connection is a real OS process. Not a thread. A process, with its own memory footprint, typically 5 to 15 MB on a default config. The reason for this design is historical (Postgres predates threads being good at anything in 1996) and operational (process isolation makes one crashed query much less likely to take down the whole server). The cost is that connections are expensive.

So Postgres caps them with max_connections. The defaults you will see in the wild:

Supabase free tier: 60 (direct), but with their Supavisor pooler in front
Neon free tier: 100 via their built-in pooler, ~20 direct
Heroku Postgres Mini: 20
Heroku Postgres Basic: 20
RDS db.t4g.micro: 81
Self-hosted Postgres on a 2 GB VPS, default config: 100

Hit the cap and Postgres does not slow down. It refuses. FATAL: too_many_connections for role "app". Your application's retry logic kicks in. Cold-start serverless functions fan out, each opening its own connection, each getting rejected, each retrying. Your queue backs up. Within 90 seconds the system is fully wedged and the only fix is to restart enough of your app servers to drop the held connections.

I have watched this happen to three clients in the last six months. One of them was a Bolt-built B2B tool that survived its private beta and died on its public launch with 41 concurrent users.

Why this bites indie SaaS specifically

Big companies do not hit this because they paid a platform team to set up connection pooling five years ago. Indie founders hit it because three things stack:

The first is serverless and edge runtimes. Every Vercel function, every Lambda, every Netlify function that touches your database wants its own connection. A single page load on a modern Next.js app can spin up 4 to 8 functions in parallel (your loader, your action, your middleware, your API route, your auth check). Multiply by 50 concurrent users and you are at 400 simultaneous connection attempts to a database that allows 100.

The second is ORM defaults. Prisma, by default, opens a connection pool sized to your CPU count, per process. Run that on 10 Vercel functions and you have 10 separate pools, each sized to whatever Vercel reports as CPU count, often 4 or 8. Drizzle's node-postgres driver defaults to a pool of 10. SQLAlchemy defaults to pool_size=5, max_overflow=10. Stack a few worker dynos and a web server and you can blow past your max_connections limit without doing anything wrong.

The third is hot reload during development. Run npm run dev with Prisma and every save spawns a new client without closing the old one (this got better in recent Prisma versions but is still common). On a small free-tier database, three hours of local dev can hold 30 connections that the database never sees you releasing.

If any of those three apply to you (and at least one does), you are one Product Hunt feature away from the outage I just described.

The math you should actually do tonight

Before reaching for PgBouncer or Supavisor or any pooling layer, do the arithmetic. The formula is brutal but honest.

Take your real concurrency target. For most indie SaaS that is 50 simultaneously active users, not 50,000. Multiply by 2 to account for the fact that a single user action often hits 2 to 4 endpoints (page load, auth check, data fetch, mutation). Add a buffer of 20% for background workers, cron jobs, the Postgres backup process, and your own psql sessions. That is your connection demand.

Now look at your max_connections. Subtract 5 for Postgres's own internal processes (autovacuum, wal writer, etc). What is left is your real budget.

For a Heroku Postgres Basic at 20 max_connections, your real budget is 15. Divide by your per-process pool size, and you get the number of app processes you can safely run. If Prisma is opening 10 connections per process, you can run 1.5 processes. That is your headroom. One Heroku web dyno plus one worker dyno will already be over the limit, before any user shows up.

This is the math nobody runs.

When you need PgBouncer, and when you just need to fix your app

PgBouncer (or Supavisor, or PgCat, or your provider's built-in pooler) lets a small number of real Postgres connections back a much larger number of fake-looking client connections. Your 500 Next.js functions all open a connection to PgBouncer on port 6432. PgBouncer holds 15 real connections to Postgres on port 5432 and multiplexes them. As long as no single query holds a connection for too long, your fan-out problem disappears.

But pooling is not the first fix. It is the third.

Before adding a pooler, do these in order:

First, lower your ORM's per-process pool size. Most Prisma deployments do not need 10 connections per process. Set connection_limit=2 in your DATABASE_URL query string. For Drizzle/node-postgres, pass { max: 3 } to the pool constructor. For SQLAlchemy, set pool_size=2, max_overflow=0. This alone solves the issue for most indie SaaS.

Second, stop opening new clients on hot reload. The Prisma docs have a singleton pattern for Next.js dev mode that uses globalThis to reuse the client across reloads. Use it. SQLAlchemy users should make sure they are not calling create_engine() inside a request handler.

Third, find your connection leaks. Run SELECT pid, query, state, backend_start, state_change FROM pg_stat_activity WHERE state = 'idle in transaction' ORDER BY state_change ASC; against your production database. Any row older than 5 minutes is a leak. It is almost always a missing await on a transaction, or an error path that does not call client.release(). Fix those before adding any infrastructure.

If after all three you still need more headroom, then add a pooler.

The PgBouncer config that actually works

If you self-host PgBouncer, the minimum useful config is shorter than people think:

[databases]
appdb = host=10.0.0.5 port=5432 dbname=appdb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 500
default_pool_size = 15
reserve_pool_size = 5
reserve_pool_timeout = 3
server_idle_timeout = 60

The two settings that matter are pool_mode and default_pool_size. pool_mode = transaction is what makes the multiplexing actually work: PgBouncer hands a real Postgres connection to a client only for the duration of a single transaction, then reclaims it. default_pool_size = 15 means PgBouncer will open up to 15 real connections to Postgres per (user, database) pair. That number, plus a buffer, must stay under your max_connections.

max_client_conn = 500 is the lie you tell your application. From the app's perspective there are 500 connections available. From Postgres's perspective there are 15. PgBouncer mediates.

The prepared statement footgun

Here is the part that bites everyone, including me, the first time.

In pool_mode = transaction, a single client connection can land on different real Postgres connections from one transaction to the next. Prepared statements (PREPARE name AS SELECT...) live on a specific Postgres connection. So if your ORM prepares a statement on connection A and then tries to execute it on connection B because PgBouncer rotated, you get prepared statement "p1" does not exist. Your app starts throwing 500s on perfectly correct queries.

This hits Prisma users hard because Prisma uses prepared statements by default. The fix is either:

Use Prisma's ?pgbouncer=true flag in the connection string, which disables prepared statements
Or upgrade to Prisma 5.10+ and use ?statement_cache_size=0
Or run Prisma against Postgres directly and use PgBouncer only for non-Prisma workloads
Or use Supabase's Supavisor in "session mode" instead of transaction mode (less efficient, but compatible)

Django users with psycopg2 need DISABLE_SERVER_SIDE_CURSORS = True in their database config. Rails with the pg gem is mostly fine because Rails does not use prepared statements by default in production unless you opted in via prepared_statements: true.

SQLAlchemy users need pool_pre_ping=True and to make sure they are not using server-side cursors across transactions. The default is fine.

This is the one chunk of this article I would tape to your monitor. The error message prepared statement does not exist after introducing PgBouncer is not a bug in PgBouncer. It is your ORM assuming pool_mode = session when you gave it pool_mode = transaction.

What about Supabase, Neon, and the managed providers

Most of them already do this for you, kind of.

Supabase ships a pooler called Supavisor in front of every project. Your DATABASE_URL for "direct" connections hits Postgres on port 5432. Your "transaction" pooler URL hits Supavisor on port 6543. Use the latter from any serverless context. The former is fine for migrations, long-running scripts, and Studio.

Neon does similar with a pgbouncer-derived layer. Append ?pgbouncer=true to your connection string and you are using their pooled endpoint.

Render's managed Postgres has a built-in pooler since 2024, configured via the dashboard.

Heroku Postgres has no built-in pooler. You either run PgBouncer yourself on a separate dyno, or you switch providers.

The trap: founders use the pooled URL in their .env for everything, then run Prisma migrations through it, and the migration fails because migrations need session-mode features like advisory locks and SET search_path. So you keep two DATABASE_URL values: one for the app (pooled, transaction mode), one for migrations (direct, session mode). Most ORMs let you point migrations at a different URL via env var. Do that.

What I built

I kept solving this manually for clients, then I packaged it. I run Belmo, a small European PaaS where the managed Postgres ships with a pooler in front by default on every plan, and the dashboard surfaces pg_stat_activity so you can see your idle-in-transaction count before it kills you. There is also AI-driven log monitoring that pattern-matches too_many_connections and prepared statement does not exist and pings you on Telegram with the likely root cause. EU and US data centers, GDPR baked in. The free Starter tier never sleeps, which matters when your Product Hunt launch happens at 02h Paris time.

That is the one mention. The actual fix in this article works the same on Render, Fly, Supabase, or your own VPS. Pick the provider that fits.

What to do tonight regardless of which platform you use

Run SELECT count(*), state FROM pg_stat_activity GROUP BY state; against your production database right now. If idle in transaction is non-zero, you have a leak.

Open your .env or your platform's env vars page. If your DATABASE_URL has no connection_limit parameter (Prisma) or no pool size in the connection options (other ORMs), add one. Set it to 2 or 3.

Check whether your managed Postgres provider offers a pooled connection URL. Switch your serverless functions to use it. Keep the direct URL for migrations only.

Add an alert (Sentry, your log aggregator, Telegram, whatever you use) for the exact strings too_many_connections and prepared statement does not exist. Both indicate you are about to have a bad day.

If you self-host, install PgBouncer with pool_mode = transaction and the config above, and set default_pool_size to no more than max_connections - 5 divided by however many user-database pairs you have.

Document somewhere (a README, a Notion page, your project's ARCHITECTURE.md) what your real max_connections is and how many connections your app is allowed to take. Future-you on Product Hunt day will thank present-you.

What I do not know

The interesting open question for me is whether the next generation of "thin client" Postgres protocols (the HTTP-based ones like Neon's Serverless Driver and Supabase's PostgREST) make all of this obsolete. They sidestep the connection-per-process model entirely by going stateless. They also break every ORM that assumes a persistent connection.

My current bet is that the connection pool will remain the right abstraction for the next 3 to 5 years, because the alternative is rewriting your data layer for a protocol that has no transactions in the traditional sense. But I would love to hear from anyone running an indie SaaS on the new thin-client protocols. What broke? What got easier? Drop a comment.

Previous posts in this series

Your .env file is probably already in your Git history. The 15-minute audit (and the 5 habits that stop new leaks for good).

Chalom Ellezam — Mon, 15 Jun 2026 18:21:48 +0000

Disclosure: I am a senior backend tech lead in Paris and I run Belmo, a small European PaaS. This article mentions Belmo once near the end. Everything else works regardless of where you host.

A founder I advise forwarded me a GitHub email last Sunday. Subject line: "We found a secret in one of your repositories." It was an OpenAI key, six commits old, in a repo she had flipped from private to public on Friday so a designer could browse it. The key was still active. She had been billed €240 in API calls between Friday evening and Sunday morning by someone running what looked like a CSV-to-embeddings job out of a residential IP block in Brazil.

This is the most common preventable production incident I see in indie SaaS. Not a database outage, not a Stripe bug, not a deploy gone wrong. A key in a place it should not be. Usually a .env file committed before .gitignore was set up. Sometimes a hardcoded OPENAI_API_KEY = "sk-..." in a Python script the founder forgot they pushed during early prototyping. Almost always findable in two minutes if you know where to look.

If you have ever pasted an API key into Claude Code, Cursor, Lovable, or Bolt, or if you have ever committed a project before you knew what .gitignore did, this article is the audit you have been putting off.

Why secrets leak more in 2026 than they did in 2020

Three things changed. AI coding tools often hardcode keys directly, because the model is trying to make the snippet work in front of it. The number of repos a solo founder touches per year has roughly tripled since vibe-coding caught on. And the providers each app talks to (Stripe, OpenAI, Anthropic, Resend, Twilio, Supabase, Cloudflare R2) have gone from two or three to ten or fifteen.

More repos times more providers times more "just paste it in" equals more leaks. The audit is cheap, the prevention is mostly free.

The 15-minute audit you can run tonight

This works on any repo. Run it on every repo you have pushed.

Step 1: scan the full Git history, not just the working tree

A common mistake is to grep for keys in current files. If you committed a secret six months ago and deleted it, it is still in history. Anyone who clones the repo gets it.

The tool I reach for is gitleaks. Install it once (brew install gitleaks on macOS, or grab a binary from GitHub).

cd ~/code/your-app
gitleaks detect --source . --verbose

This scans your entire commit history with a set of regex rules that match common provider patterns (Stripe, GitHub, AWS, OpenAI, Anthropic, Slack, and many more). On a typical indie project I have audited, this finds something in 6 cases out of 10. The classic findings are an old .env from before the project had a .gitignore, a forgotten test.py with a hardcoded key, or a docker-compose.override.yml that someone committed by accident.

If gitleaks reports nothing, run trufflehog as a second opinion. It has slightly different heuristics:

trufflehog filesystem --directory=. --no-update

Step 2: check GitHub's secret scanning UI

If the repo lives on GitHub, GitHub itself has been scanning your pushes for known secret formats since 2023. Even on free private repos. Go to your repo, Security tab, Secret scanning alerts. Anything GitHub already caught will be listed there with the exact commit and line.

If you see anything there, treat it as real. GitHub notifies the provider (Stripe, OpenAI, etc.) so the key may be auto-revoked, but do not rely on that. Some providers do, some do not.

Step 3: rotate every key the audit found

This is the part people skip because it is annoying. You log in to each provider, generate a new key, swap it in your hosting platform's env var settings, redeploy, and verify the old key is dead.

A habit that helps: keep a secrets-rotation.md in a private vault listing every provider, the last rotation date, and the URL of that dashboard's "API keys" page. When you audit, you walk down the list. The hardest part of rotation is not the rotation itself, it is remembering all the places a key lives.

For OpenAI and Anthropic specifically, do not just create a new key and leave the old one active. Revoke the old one explicitly. A leaked key that has been rotated but not revoked is the same as a leaked key.

Step 4: purge the secret from Git history (optional but worth it for public repos)

If your repo is private and you trust everyone with read access, rotating is enough. The leaked key is dead, anyone who finds it later gets a 401.

If your repo is public, or was public at any point, or you simply do not want a paper trail of "things I shipped that I should not have," you can rewrite history with git filter-repo:

pip install git-filter-repo
git filter-repo --invert-paths --path .env
git push --force --all

This rewrites every commit and force-pushes. Do not do this on a repo where other people have open branches without warning them. For a solo project, it is fine and takes about 30 seconds.

A note: even after a force push, GitHub keeps orphan commits accessible by SHA for a while. The only real fix for a leaked credential is rotation. Rewriting history is cosmetic.

The 5 habits that stop the next leak

Auditing is the fire drill. Habits are how you stop the next fire.

Habit 1: `.gitignore` is the first file in every new repo

Before you write any code, before the first commit, the first file is .gitignore and it includes .env, .env.local, .env.*.local, and anything provider-specific like firebase-adminsdk-*.json or gcp-key.json.

If you use AI coding tools, add this to your starter prompt or to your CLAUDE.md/.cursorrules: "Never write secrets or API keys directly in source files. Always read them from process.env.X or os.getenv('X'). Never commit .env or .env.local." Models will mostly respect this. They will occasionally forget, which is why you also need habit 2.

Habit 2: a pre-commit hook that runs `gitleaks`

The cheapest possible defense. Install pre-commit (pip install pre-commit --break-system-packages) and drop a .pre-commit-config.yaml in your repo:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

Then run pre-commit install once. From that point on, every git commit runs gitleaks against the staged diff. If you paste a key into a file by accident, the commit is blocked.

This single setup has saved at least four founders I work with from an embarrassing rotation. It takes 90 seconds to install and you forget it exists.

Habit 3: prod env vars live in the hosting platform, never in a file on disk

Every modern hosting platform (Vercel, Fly, Railway, Render, Belmo, you name it) has an "environment variables" section in the dashboard. Production secrets go there. They never live in a file that gets deployed. They are injected at build time or at process start.

The mental model I push founders toward: your repo contains the code and a .env.example (no real values, just keys with empty strings). The hosting platform contains the real values. Local dev uses a .env file that is in .gitignore. Three places. No overlap.

A subtler version: do not screenshot your env vars dashboard, and do not paste that screenshot into Slack or Discord. I have seen Stripe keys leak through Loom recordings shared with a contractor.

Habit 4: scope keys aggressively, and prefer short-lived ones

Most providers let you create restricted keys. Stripe has restricted keys with read-only or specific-resource access. OpenAI has project-scoped keys. AWS has IAM roles with specific policies. The default behavior is to create a key with full account access because it is one click. Resist that.

A production API key should be able to do exactly what your app does and nothing more. If it is compromised, the blast radius is small. A founder I worked with last quarter had an AWS key with full admin access in a repo. The leak resulted in a small bitcoin-mining incident on her account that AWS reversed, but only after a week of stress. A scoped S3-only key would have made it "someone uploaded weird files to a bucket." Recoverable in 20 minutes.

For human access, use SSO and a password manager. Do not share login passwords with contractors. Use the vendor's "invite teammate" flow even if it costs a few euros a month. The audit trail alone is worth it.

Habit 5: a monthly 5-minute rotation calendar event

Once a month, on the same day, you spend 5 minutes rotating one or two keys. Not all of them, just the highest-risk ones (the ones that can spend money). OpenAI, Anthropic, Stripe, your cloud provider. Over a year you rotate everything at least once.

This sounds like security theater. It is not. The point is to keep the rotation muscle warm so that when you actually need to rotate in a hurry (someone leaks a key on a Friday night), you already know which dashboard pages to open and what app code reads which env var. Without the muscle, you spend the first 45 minutes of an incident just orienting yourself.

What I built (the one Belmo mention)

I built Belmo in part because I kept solving this problem manually for clients. The platform has encrypted env vars by default on the Hobby tier (€19/month), restricted access logs that show which deploy injected which secret, AI monitoring that catches anomalous token usage patterns the moment a leaked OpenAI key starts being used by someone else, and Telegram alerts when a deploy starts behaving unlike its baseline. None of that is unique to Belmo. Most modern platforms have at least the env var encryption part. The piece I cared most about was making the secret-rotation flow take 30 seconds instead of 10 minutes, because friction is why founders skip rotation.

If you are happy on Vercel, Fly, Railway, Render, or anywhere else, this article still works. The point is the habit, not the host.

What to do tonight regardless of which platform you use

Five concrete moves you can make in the next hour.

First, install gitleaks and run it against every repo in ~/code (or wherever you keep them). A one-liner for macOS:

brew install gitleaks
find ~/code -name ".git" -type d -maxdepth 3 \
  | while read d; do
      echo "=== $(dirname $d) ==="
      gitleaks detect --source "$(dirname $d)" --no-banner 2>&1 | tail -5
    done

Second, log in to GitHub and check the Secret scanning alerts tab on each of your repos. Anything sitting there has been visible to GitHub (and possibly to others) for as long as it has been there. Address it.

Third, rotate any key the audit found. Do not skip this. Revoke the old key explicitly in the provider's dashboard.

Fourth, install the pre-commit hook with gitleaks on your primary working repo. 90 seconds of setup, infinite future leak protection on that repo.

Fifth, put a recurring calendar event titled "Secret rotation, 5 minutes" on the first Monday of every month. When it fires, you rotate one provider key. Pick the highest-value one you have not rotated this year.

If you do these five things tonight, you have closed the biggest preventable security gap in your stack. The rest is just keeping the habit.

An honest closing

I have leaked a key in my own career. Twice. Once in 2017 when I committed an AWS key to a public-ish demo repo and got billed €80 of EC2 inside 6 hours. Once in 2022 when a Stripe test key ended up in a Loom recording sent to a client (test key, thankfully). Both times I learned the same lesson: the question is not "will a key leak" but "what is your detection and rotation time when it does." The audit and habits above bring that time from "weeks" to "minutes."

Here is the question I will leave you with. When was the last time you actually rotated a production API key, on purpose, without an incident forcing you to? If the answer is "never" or "I do not remember," your monthly calendar event starts tonight.

Drop a comment if you have a different rotation cadence that works for you, or if you have a horror story to share. I read all of them. We learn from each other's leaks more than from any best-practices doc.

Previous posts in this series

5 Heroku alternatives whose free tier doesn't sleep
I built my MVP with Claude Code. Now I need to deploy it.
Your AI app is silently burning $2,000/month
Telegram alerts for any production app in 5 minutes
How I built a Discord ship-tracker bot in a weekend
I migrated 12 client projects off Heroku. Here's the playbook.
The Claude Code production checklist: 15 things that aren't obvious
Your indie SaaS has zero working Postgres backups
Your Stripe webhook is going to silently drop a paid customer
Your crontab is silently failing: 5 silent killers of VPS cron
I deployed 12 vibe-coded apps. The same 6 things broke.

I deployed 12 vibe-coded apps to production. The same 6 things broke every single time.

Chalom Ellezam — Wed, 20 May 2026 08:01:06 +0000

Disclosure: I am a senior backend tech lead in Paris and I run Belmo, a small European PaaS. This article mentions Belmo once near the end. The content works on any platform you choose.

Last month, a non-tech founder messaged me at 23h on a Tuesday. Her Lovable-built waitlist had hit Product Hunt at noon Pacific, racked up 4,000 signups by dinner, and the dashboard was now returning a blank white screen. She had pushed nothing. Nothing changed. She also could not log in to her own admin panel.

I have seen this exact failure mode roughly 12 times in the last 8 months. Different founder, different tool (sometimes Lovable, sometimes Bolt, sometimes Cursor, sometimes Claude Code), same six holes. The code the model wrote was fine. Production exposed assumptions the model could not see.

This is a field guide to those six holes. If you have shipped (or are about to ship) anything you built with an AI coding tool, you will recognize at least three of them.

Why vibe-coded apps fail in production specifically

A coding model writes the code in front of it. It does not see your DNS, your env vars, your cold-start behavior, your database connection limits, your timezone, or the fact that your "production" environment is actually your laptop with ngrok pointed at it.

Models are also trained on a corpus where "it works locally" usually means "it works." For a side project on a single laptop, that is true. For a deployed app with real users on real networks across real timezones, it is wildly false. The model is not lying. It just has no production telemetry. You have to add that yourself.

Here are the six patterns. Each one I have personally pulled out of a vibe-coded codebase in the last year.

Pattern 1: The API key that shipped in the JS bundle

Roughly 7 out of 12 vibe-coded apps I audited had at least one API key directly in client-side code. The model put it there because the model was told "call the Stripe API from this React form." The model did not say "by the way, this key is now visible to every browser on Earth via View Source."

The tell: you grep the dist/ or .next/ build output for the first few characters of your key, and you find it.

# Run this against your built output before deploying
cd dist && grep -r "sk_live_" . || echo "Clean"
cd .next && grep -r "sk_live_" . || echo "Clean"

Fix: every secret call goes through a backend route. The client sends a request to your server. Your server, holding the secret in an env var, calls the third party. Even for a static site, you can run a tiny serverless function or a single Express route for this. Costs nothing, takes 15 minutes.

If you only learn one thing from this post, learn this one. Leaked Stripe keys, leaked OpenAI keys, and leaked Resend keys cost real money and real customer trust. I have seen one founder rack up $1,800 in OpenAI charges in 11 hours because a leaked key got scraped off a GitHub mirror.

Pattern 2: The unbounded query that nukes the database

The model writes SELECT * FROM users WHERE org_id = ? and it works fine because in development you have 4 users. The same query in production, when your largest customer has 80,000 users, returns 80,000 rows over the wire, into your Node process, into JSON, and onto the network. Your API server's memory spikes. Your database connection pool gets exhausted. Your dashboard returns the blank white screen.

This is the most common Lovable / Bolt failure I see, by a wide margin.

The fix is paginate everything and put an upper bound on every query. Pick a default limit (50 is fine for most things), enforce it at the query layer, and only allow the client to ask for more in explicit chunks.

// Bad (what the model wrote)
const users = await db.query('SELECT * FROM users WHERE org_id = $1', [orgId]);

// Better
const limit = Math.min(parseInt(req.query.limit) || 50, 200);
const offset = parseInt(req.query.offset) || 0;
const users = await db.query(
  'SELECT * FROM users WHERE org_id = $1 ORDER BY id LIMIT $2 OFFSET $3',
  [orgId, limit, offset]
);

While you are in there, add an index on the column you are filtering by. Most vibe-coded apps have zero indexes outside the ones the ORM created automatically on primary keys.

Pattern 3: The CORS wildcard that opens the front door

Every model I have worked with, when asked "I am getting a CORS error," will reliably suggest setting Access-Control-Allow-Origin: *. It removes the error. It also opens your API to every site on the public internet, which is a problem the moment you have a session cookie or an auth token.

The right answer is to whitelist your own domain (and your staging domain, and localhost:3000 for dev).

// Express
const allowedOrigins = [
  'https://yourapp.com',
  'https://staging.yourapp.com',
  'http://localhost:3000',
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
}));

If your AI tool wrote app.use(cors()) with no options, you have a wildcard. Audit it.

Pattern 4: The timezone mismatch nobody notices until billing

Your server is on UTC. Your dev laptop is on Paris time, or PST, or Bangalore. Your users are everywhere. The model probably wrote new Date() in a dozen places and the dates look "correct" to you because you are the only person who has looked at them.

Then a customer in Tokyo says "your invoice has the wrong month" and you discover that your billing cron, which runs at "midnight" your time, actually fires on the wrong day for half your customer base.

Three rules that catch most of these:

Store everything in UTC in the database. Always. ISO 8601, with the Z. If your ORM is doing anything else, fight it.

Display in the user's timezone, computed on the client side or with the user's stored preference. Never assume server-local.

For scheduled jobs (billing runs, daily digests, weekly emails), use cron-style scheduling that is explicit about timezone, or schedule them in UTC and document the offset.

// Use Intl on the client for display
const userTz = Intl.DateTimeFormat().resolvedOptions().timeZone;
const formatted = new Intl.DateTimeFormat('en-US', {
  timeZone: userTz,
  dateStyle: 'medium',
  timeStyle: 'short',
}).format(new Date(isoStringFromAPI));

This bug compounds with Pattern 2. If you have an unbounded query plus a bad timezone, you can ship invoices in the wrong currency to the wrong country with no audit trail. I have seen it.

Pattern 5: The file path that works on your laptop and nowhere else

fs.readFileSync('./data/seed.json') works perfectly when you run npm start from your project root. It explodes when your deploy runs from a different working directory, or when the file got excluded by your .gitignore, or when your build step did not copy it into the production bundle.

Same pattern: import config from '../../config/local.json'. The relative path resolves in development. In production, after the bundler did its thing, the path no longer exists.

The fix is to treat config as environment variables (the 12-factor way) and to load runtime data from a real data store, not from disk.

// Bad
const config = require('./config/local.json');

// Better
const config = {
  apiUrl: process.env.API_URL,
  dbUrl: process.env.DATABASE_URL,
  stripeKey: process.env.STRIPE_SECRET_KEY,
};

// Validate at boot so you fail loudly, not silently
const required = ['API_URL', 'DATABASE_URL', 'STRIPE_SECRET_KEY'];
const missing = required.filter(k => !process.env[k]);
if (missing.length) {
  console.error('Missing env vars:', missing.join(', '));
  process.exit(1);
}

That process.exit(1) is doing a lot of work. It is the difference between "the app crashes loudly at boot with a clear error" and "the app appears to boot fine but then 500s on the first request that needs Stripe."

Pattern 6: The background work that never runs

Sending an email after signup. Charging a customer's card on the 1st of each month. Cleaning up expired sessions. The model wrote these as inline calls inside your HTTP handler, or as setTimeout calls that get dropped when the process restarts.

The first time you redeploy, the queued work disappears. The first time your server cold-starts, the in-memory timers vanish. The first time an email fails to send (because Mailgun returned a 429), your signup handler returns 500 and the user thinks the app is broken.

You need three things: a real background process (a worker), a real schedule (cron, not setTimeout), and retry logic with a dead-letter behavior.

Lightweight options that have worked for me on small teams: BullMQ on top of Redis, RQ for Python, Sidekiq for Rails, GoCron for Go. Or use your platform's managed worker tier if it has one.

The pattern in code:

// In the HTTP handler, do NOT send the email inline
await db.users.create({ email, hashedPassword });
await emailQueue.add('send-welcome', { userId: newUser.id });
return res.json({ ok: true });

// In the worker process
emailQueue.process('send-welcome', async (job) => {
  const user = await db.users.findById(job.data.userId);
  await mailer.send({
    to: user.email,
    template: 'welcome',
  });
  // BullMQ retries automatically with exponential backoff
});

If something fails repeatedly, it goes to the dead-letter queue and you see it in a dashboard. The user's signup never broke. The email gets retried until it succeeds, or you decide it is hopeless.

What I built, because I kept solving these manually

After roughly the eighth time a non-tech founder messaged me at midnight with a vibe-coded app on fire, I built Belmo. It is a small European PaaS that runs your app from a GitHub repo, gives you a worker process if you need one, and watches your logs with a pattern-detection layer that catches the failure modes above (retry loops, hot Sentry fingerprints, latency spikes, silent cron failures) and pings me on Telegram. Free tier never sleeps, EU and US regions, encrypted env vars by default.

I am not telling you to use it. The patterns above work on Render, Railway, Fly, Vercel, AWS, or a Hetzner box you set up yourself. The point is: pick a platform that lets you have a worker process, real env vars, and log access. If your current setup does not, fix that before anything else.

What to do tonight, regardless of which platform you use

If you have a vibe-coded app in production right now, run this sweep. 30 minutes, maybe 45.

grep -r "sk_live_\|api_key\|secret" dist/ .next/ public/ build/ against your built output. If anything matches, move the call to a backend route before you sleep.
Open your three most-used database queries. Check for LIMIT. If it is missing, add it and a default of 50.
Search your codebase for cors() with no arguments, or Access-Control-Allow-Origin: *. Replace with a whitelist of the 2 or 3 origins you actually need.
Pick one date-handling code path (signup, billing, scheduled email). Verify it stores UTC and displays in user-local. If you cannot tell, log the Z suffix on the stored string and the Intl.DateTimeFormat output on the client.
List your env vars. For each one, ask: would my app boot, or would it boot and then 500 on the first relevant request? Add a boot-time validator that crashes the process loudly if anything is missing.
Find the one most important background job (welcome email, daily report, billing run). Verify it runs in a worker process or scheduled cron, not inside an HTTP handler.
Set up one alert. Telegram, email, Slack, anything. The trigger does not need to be smart. "Error rate above 1% for 5 minutes" or "background job failed 3 times in a row" is enough to catch 80% of the bad nights.

The honest closing

Vibe-coded apps are not bad. They get founders shipping who otherwise could not ship, and that is wonderful. But the production gap is real, and every model I have used (Claude included) will confidently generate code that hides the six holes above. The model is doing what it was asked. You have to ask the next question.

I am curious: which of these six bit you the hardest? Or did you hit one I did not list? I have a strong suspicion there is a seventh I have not seen yet, and the comments here have been a good source of bug reports in the past.

Previous posts in this Belmo series:

Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep.
I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.
Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.
Telegram alerts for any production app, a 5-minute setup (no SaaS, no signup, just curl)
How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)
I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).
The Claude Code → production checklist: 15 things that aren't obvious until they bite you
Your indie SaaS has zero working Postgres backups. Here's the 20-minute fix.
Your Stripe webhook is going to silently drop a paid customer. Here are the 4 patterns that catch it before they chargeback.
Your crontab is silently failing. The 5 silent killers of VPS-based cron jobs.

Your crontab is silently failing. The 5 silent killers of VPS-based cron jobs (and the modern setup that fixes them in an afternoon).

Chalom Ellezam — Sun, 17 May 2026 07:34:10 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo. This article mentions Belmo once at the end, but the patterns and the fix work on any platform. The point is to stop losing scheduled jobs in silence, not to sell you anything.

It's Monday, 9:17 AM. The weekly digest email didn't go out. The Discord channel you wired to announce new signups is suspiciously quiet. You SSH into the $12 droplet that runs your scheduled jobs. crontab -l looks fine. /var/log/syslog says the job ran at 06:00. You open the output log. Empty.

You don't know if the script crashed, if it sent the emails but logged nothing, or if cron started a second run before the first one finished and the two are now stepping on each other. You spend an hour digging instead of writing code.

I've onboarded thirty-something teams off VPS-based cron in the last 14 months. The story is always a variation of the above. Cron itself isn't broken (it's been working since 1975). What's broken is the operational layer around cron when you run it on a generic Linux box you maintain yourself. Below are the 5 silent failure modes I see most often, and the modern setup that retires all of them.

Killer #1: you edited the wrong crontab

There are at least four places on a stock Ubuntu box where a cron job can live: the user's crontab (crontab -e), the root crontab (sudo crontab -e), /etc/crontab, and any file inside /etc/cron.d/. They use slightly different syntax (/etc/crontab and /etc/cron.d/* require a username field, the user-level crontab does not). Copy a snippet from a blog post into the wrong file and it silently does nothing. No error, no warning, no run.

I once watched a senior engineer (ex-Oney, plenty of Linux years on him) lose an hour to this on a Friday afternoon. The fix isn't "be more careful". The fix is to not have four places where the same job could live.

Killer #2: the environment your job runs in isn't your shell

Cron jobs run with a near-empty environment. No .bashrc, no .profile, no nvm, no pyenv. PATH is usually /usr/bin:/bin, which means your job can't find node if you installed it through nvm, can't find python3.11 if you're on a pyenv setup, and can't find psql if you installed Postgres client tools through a custom apt repo.

The classic symptom: the job runs interactively when you test it from your shell, runs silently as cron, and you discover three weeks later that which node returned a different path under cron than under your login session.

People work around it with line one of every crontab being:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/bash

That helps with binaries. It doesn't help with secrets. Your DATABASE_URL is in ~/.env and you assumed source ~/.env runs. It doesn't (cron uses /bin/sh by default, not your interactive bash). You end up wrapping every job in:

0 6 * * * cd /srv/app && set -a && . ./.env && set +a && node scripts/digest.js >> /var/log/digest.log 2>&1

That's a lot of ceremony for "run this script every morning."

Killer #3: output goes to /dev/null, errors go nowhere

The default cron behavior is to email the user the script's stdout and stderr. On a fresh VPS, there's no mail transport configured, so the output gets discarded. Most people add > /dev/null 2>&1 to silence the warning messages. Now you have no error output anywhere.

When the job crashes, you find out because a customer complains. Then you SSH in, scroll back through /var/log/syslog, see that the cron daemon dutifully started your command, and have zero idea what happened inside it.

The minimum fix is to log everything:

0 6 * * * /srv/app/scripts/digest.sh >> /var/log/digest.log 2>&1

Better: pipe to a tool like logger so it ends up in journald with proper tagging, so journalctl -t digest returns history:

0 6 * * * /srv/app/scripts/digest.sh 2>&1 | logger -t digest

Best: have your script itself report its own success or failure to somewhere you actually read, like a Telegram chat or a Slack channel. I wrote a whole post on the Telegram side of that (linked at the bottom).

Killer #4: your VPS is a single point of failure

The droplet reboots after a kernel update. The cron jobs run again as soon as the box comes back up, on the OS's clock. Fine, except your provider's clock skewed two minutes during the reboot and now your "every minute" health-check job and your "every five minutes" reconciliation job briefly overlap. Or the reboot took 8 minutes and the 06:00 digest didn't fire at all because the box wasn't on.

Worse case: the disk fills up because nobody rotates /var/log/digest.log. Cron itself starts failing because it can't write its own log file. You don't notice until a customer tells you the app is acting strange.

I have a slide I use in onboarding calls that just says "production scheduled jobs should not depend on the uptime of a Linux box you personally maintain." Half the room nods. The other half says "but it's so cheap." It is cheap, until the day it isn't.

Killer #5: overlapping runs corrupt your data

This is the one that bit a client most recently. SaaS doing inventory sync for indie ecommerce shops. The reconciliation job runs every 15 minutes. Normally it takes 3 minutes. Then their database hit a slow week, the job started taking 18 minutes, and now job N+1 starts while job N is still writing. Two simultaneous writers on the same Postgres rows. Half the inventory counts ended up wrong. They didn't notice for 4 days because the symptom was "some products show wrong stock", not "the script crashes."

The fix is locking. The simplest version is flock:

*/15 * * * * /usr/bin/flock -n /tmp/reconcile.lock /srv/app/scripts/reconcile.sh

flock -n exits immediately if another instance holds the lock, instead of queuing. That prevents the overlap. It does not tell you that an overlap happened, so you can silently skip every 15-minute job for an hour and never notice. You only know if you instrument the script itself.

At the database level, pg_try_advisory_lock does the same thing inside Postgres:

SELECT pg_try_advisory_lock(54321);
-- ... do work ...
SELECT pg_advisory_unlock(54321);

Either is fine. Neither shows up in the tutorial that taught you cron in the first hour. They become obvious only after you've been bitten.

The modern setup, in three pieces

I'll describe this generically because every reasonable PaaS in 2026 supports it. The three pieces are:

First, a scheduled job primitive your platform manages. You declare "this command, this schedule" in config or a UI. The platform handles when the box reboots, when the cron daemon misbehaves, when overlapping runs need to be prevented. Render and Railway both call them Cron Jobs. Fly has scheduled Machines. The naming varies. The pattern is the same: the platform owns scheduling, you own the script.

Second, per-run logs you can actually read. Not a log file you have to SSH and tail. Logs in a UI, by run, with timestamps and exit codes. This is the single biggest quality-of-life upgrade over crontab. You stop debugging "did it run?" and start debugging "what did it print?".

Third, alerts on failure that go to a channel you check. If exit code is non-zero, ping Telegram or Slack. Not email. Email gets buried (see article 4 in the series).

That's the minimum. You can add nice-to-haves: retries with backoff, run history, manual "run now" buttons for debugging, isolation so a runaway job doesn't take down your web service. But scheduling, logs, and alerts is the floor.

A real before/after

I'll show you the kind of script most indie SaaS use for a weekly digest. The "before" is what I see on VPS boxes. The "after" is the same script with proper instrumentation that works on any platform that gives you the three pieces above.

Before (digest.sh on a VPS, dropped into crontab -e):

0 9 * * 1 cd /srv/app && /usr/bin/node scripts/digest.js > /dev/null 2>&1

After (digest.js, run by the platform's scheduler, logs and alerts built in):

// scripts/digest.js
const start = Date.now();
const TELEGRAM_TOKEN = process.env.TELEGRAM_TOKEN;
const TELEGRAM_CHAT = process.env.TELEGRAM_CHAT_ID;

async function notify(text) {
  if (!TELEGRAM_TOKEN) return;
  await fetch(`https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ chat_id: TELEGRAM_CHAT, text }),
  });
}

async function run() {
  console.log(JSON.stringify({
    event: "digest.start",
    at: new Date().toISOString(),
  }));

  const sent = await sendWeeklyDigest(); // your code
  const ms = Date.now() - start;

  console.log(JSON.stringify({
    event: "digest.done",
    sent,
    ms,
  }));

  if (sent === 0) {
    await notify(`Weekly digest sent 0 emails (took ${ms}ms). Investigate.`);
  }
}

run().catch(async (err) => {
  console.error(JSON.stringify({
    event: "digest.error",
    error: err.message,
    stack: err.stack,
  }));
  await notify(`Weekly digest FAILED: ${err.message}`);
  process.exit(1);
});

Three things changed: structured JSON logs (your platform's log viewer can filter them), a Telegram ping on actual failure or zero-send anomaly, and an explicit non-zero exit code so the platform marks the run as failed. None of this is exotic. All of it was inconvenient enough on a VPS that most people skipped it.

The Python version is the same shape. logging.info(json.dumps({...})), requests.post to Telegram, sys.exit(1) from the exception handler. Six extra lines around your real script. The win is that you can answer "did Monday's digest succeed?" in under 10 seconds for the next two years.

What about background workers vs cron?

Quick clarifier because I see this confused. A scheduled job runs on a clock (every 15 minutes, every Monday at 9 AM). A background worker runs continuously and consumes a queue (process this Stripe webhook now, render this PDF on request). Different primitives. You usually need both. Running both off the same cron line is a different conversation.

What I built

I built Belmo partly because I was tired of writing the same flock plus logger plus Telegram wrapper for client after client. On the Pro tier, scheduled scripts are first-class with per-run logs, exit-code tracking, and an AI monitor that pings my Telegram bot when something looks off (silent cron failures are one of the patterns it flags, alongside the retry loops and token spikes from article 3). EU (Germany) and US (Oregon) regions, ISO 27001 and GDPR compliant. The Free Starter tier doesn't sleep if you want to try a scheduled script without paying.

You don't need Belmo for this. Render, Railway, Fly, and Heroku all offer scheduled jobs as a primitive. The point of the article is that "scheduled jobs as a primitive" should be table stakes for your stack in 2026, regardless of which platform you pick.

What to do tonight regardless of which platform you use

List every cron line on every VPS you own. A one-liner: for u in $(cut -d: -f1 /etc/passwd); do echo "=== $u ==="; sudo crontab -u $u -l 2>/dev/null; done plus cat /etc/crontab plus ls /etc/cron.d/. Write them down. You probably have more than you remember.
For each one, ask: when did it last succeed? If you can't answer in under 30 seconds, you have no observability. That's the actual problem to fix first.
Add flock -n to every job that writes to a shared resource. Five-minute change. Prevents overlap-induced data corruption.
Add structured logging to the script itself. JSON line on start, JSON line on finish, JSON line on error. Make grep digest.error your.log useful.
Add a failure ping to a channel you actually read. Telegram is the cheapest option and there's a tutorial in this series (article 4).
Pick one job, the most important one (the billing reconciliation, the daily backup, the weekly digest), and move it off the VPS to a managed scheduler this week. Don't migrate everything at once. Migrate the one that would hurt most if it silently failed for a week.
Set a calendar reminder for 30 days from today to check the success rate of that migrated job. The whole point of the migration is observability. Test that it actually delivered.

Honest closing question

The thing that keeps me up about cron isn't that it fails. It's that it fails silently and the discovery latency is measured in days. You find out when a customer complains, or the bill arrives, or the inventory is off.

What's the longest a scheduled job has been silently broken in your stack before you noticed? I want to know whether the "I lost a week on a digest that wasn't sending" story is unusually bad or whether every indie SaaS has one in the closet.

Previous posts in this series

Your Stripe webhook is going to silently drop a paid customer. Here are the 4 patterns that catch it before they chargeback.

Chalom Ellezam — Fri, 15 May 2026 07:34:55 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo. This article mentions Belmo once near the end. The four patterns below work on any platform, any framework, with any webhook provider (Stripe, GitHub, Twilio, Postmark). I want it useful even if you never become a customer.

Two weekends ago a founder I do code reviews for sent me a panicked DM at 11pm: "A customer just opened a chargeback because we never unlocked their Pro plan. Stripe says the subscription is active. What's happening?"

His webhook handler had crashed three days earlier at 3:14am on a Sunday. Stripe retried for 72 hours, gave up, marked the event as failed in their dashboard. Nobody was watching. The customer paid $49, got the same free-tier experience, asked for a refund, didn't get a fast reply, opened a dispute. By the time we caught it, his MRR was down one customer and his Stripe account had a $15 dispute fee on top. The fix took an hour. The damage took weeks to unwind.

Webhooks are the load-bearing wall of indie SaaS, and they're built on sand

If you run a SaaS that takes payments, webhooks are how Stripe tells you a customer paid, upgraded, churned, or failed to pay. The redirect after checkout is a UX nicety. The webhook is the source of truth. Without it, your database and Stripe go out of sync, and that gap is where money disappears.

The problem is that webhooks are the worst combination of "load-bearing" and "unreliable". The network blips. Your server returns 502 for the 30 seconds a deploy is booting. Your DB locks because some other query is doing a full table scan. Stripe sends duplicates on purpose (their delivery guarantee is at-least-once, not exactly-once). The webhook can arrive before your DB has the customer record if checkout.session.completed beats your post-checkout redirect.

Stripe will retry on a backoff for about 3 days, then quietly stop. After that, your state is permanently divergent unless you reconcile.

Here are the four patterns I install on every indie SaaS I touch, usually after the first dropped customer.

Pattern 1: verify signature, acknowledge fast, process async

The most common mistake I see in vibe-coded webhook handlers is doing the actual work inside the HTTP request. The handler verifies the signature, then runs through 15 lines of "if event.type is invoice.paid, update the DB, send an email, hit the analytics API, set a feature flag." All synchronous. All in the request that Stripe is waiting on.

If any of those steps is slow or fails, Stripe sees a timeout or 500 and retries. If your code is not idempotent (more on that next), you double-process. If the DB is locked, the whole request times out.

The pattern is: do the minimum in the HTTP handler. Verify the signature. Persist the raw event. Acknowledge 200. Process asynchronously.

// webhook-handler.js (Express + Postgres)
import express from 'express';
import Stripe from 'stripe';
import { db } from './db.js';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const router = express.Router();

router.post('/webhooks/stripe',
  express.raw({ type: 'application/json' }),
  async (req, res) => {
    const sig = req.headers['stripe-signature'];
    let event;
    try {
      event = stripe.webhooks.constructEvent(
        req.body,
        sig,
        process.env.STRIPE_WEBHOOK_SECRET
      );
    } catch (err) {
      return res.status(400).send(`Invalid signature: ${err.message}`);
    }

    // Persist the raw event. That's it. Process later.
    try {
      await db.query(
        `INSERT INTO webhook_events (id, type, payload, received_at, status)
         VALUES ($1, $2, $3, NOW(), 'pending')
         ON CONFLICT (id) DO NOTHING`,
        [event.id, event.type, event]
      );
      return res.status(200).send({ received: true });
    } catch (err) {
      console.error('webhook_insert_failed', { event_id: event.id, err });
      return res.status(500).send('persist failed');
    }
  }
);

The handler now does two things: verify, store. If the DB is reachable, you ack 200. If it isn't, you return 500 and Stripe retries, which is fine because step one (verify) is idempotent and step two has an ON CONFLICT DO NOTHING clause.

The actual work (granting Pro access, sending the welcome email, firing analytics) happens in a worker, which I'll get to in pattern 3.

Pattern 2: idempotency via the event ID

Stripe will deliver the same event more than once. Sometimes because of a retry. Sometimes because of their internal failover. Sometimes because of you, when you return 200 after the work succeeded but before the response made it back through your CDN.

The fix is one line of DDL:

ALTER TABLE webhook_events ADD CONSTRAINT webhook_events_pkey PRIMARY KEY (id);

Stripe event IDs are globally unique. If you make the primary key of your webhook_events table the Stripe event ID, the ON CONFLICT DO NOTHING in pattern 1 becomes your dedupe layer. The second time the same event arrives, the insert silently noops and you return 200.

The mistake to avoid: using your internal ID as primary key and the Stripe event ID as a regular column without a unique index. I've seen a team spend a week debugging "why did this customer get three welcome emails."

Idempotency in the processing layer matters just as much. When the worker picks up an event, it should write a "processed" flag in the same transaction as whatever side effect it produces. If the worker crashes in between, the next run reruns. So side effects need to be safe to repeat: granting Pro twice should be a noop, sending the welcome email twice is survivable, sending a $50 refund twice is a Tuesday-morning incident.

Pattern 3: a dead-letter queue and a worker with backoff

Once the raw events are in the table, you need a worker to drain it. The worker is simple:

// webhook-worker.js
import { db } from './db.js';
import { handleStripeEvent } from './handlers/stripe.js';

const BACKOFF = [10, 60, 300, 1800, 7200]; // seconds

async function processNext() {
  const { rows } = await db.query(`
    SELECT id, type, payload, attempts
    FROM webhook_events
    WHERE status = 'pending'
      AND (next_attempt_at IS NULL OR next_attempt_at <= NOW())
    ORDER BY received_at ASC
    LIMIT 1
    FOR UPDATE SKIP LOCKED
  `);

  if (rows.length === 0) return false;
  const event = rows[0];

  try {
    await handleStripeEvent(event);
    await db.query(
      `UPDATE webhook_events SET status = 'done', processed_at = NOW() WHERE id = $1`,
      [event.id]
    );
  } catch (err) {
    const attempts = event.attempts + 1;
    const backoff = BACKOFF[Math.min(attempts - 1, BACKOFF.length - 1)];
    const dead = attempts >= 10;
    await db.query(
      `UPDATE webhook_events
       SET attempts = $1,
           last_error = $2,
           next_attempt_at = NOW() + (INTERVAL '1 second' * $3),
           status = $4
       WHERE id = $5`,
      [attempts, err.message, backoff, dead ? 'dead' : 'pending', event.id]
    );
    console.error('webhook_process_failed', { event_id: event.id, attempts, err });
  }
  return true;
}

setInterval(async () => {
  while (await processNext()) {}
}, 2000);

FOR UPDATE SKIP LOCKED lets you run multiple workers without them stepping on each other. The exponential backoff prevents a poison-pill event from hammering your downstream services. After 10 attempts an event moves to "dead" and triggers an alert (pattern 4 handles the visibility on that).

This worker is a separate process from your web service. It is not optional. If you run it inside your web service as a setInterval, it dies when the web service redeploys or scales to zero. That is exactly the gap where the founder's chargeback story happened.

Pattern 4: the daily reconciliation cron

Patterns 1 to 3 keep drift small. Pattern 4 fixes the drift that already happened.

Once a day, fetch the source of truth and compare to your DB. For Stripe, that means iterating active subscriptions and verifying each one matches what your app thinks the customer has.

// reconcile-subscriptions.js (scheduled daily at 04:00 UTC)
import Stripe from 'stripe';
import { db } from './db.js';
import { sendAlert } from './alerts.js';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

async function reconcile() {
  const drift = [];
  for await (const sub of stripe.subscriptions.list({ status: 'active', limit: 100 })) {
    const customerId = sub.customer;
    const planTier = sub.items.data[0].price.lookup_key; // e.g. 'pro_monthly'

    const { rows } = await db.query(
      `SELECT plan FROM users WHERE stripe_customer_id = $1`,
      [customerId]
    );
    if (rows.length === 0) {
      drift.push({ type: 'missing_user', customerId, planTier });
      continue;
    }
    if (rows[0].plan !== planTier) {
      drift.push({
        type: 'plan_mismatch',
        customerId,
        dbPlan: rows[0].plan,
        stripePlan: planTier,
      });
      await db.query(
        `UPDATE users SET plan = $1, plan_synced_at = NOW() WHERE stripe_customer_id = $2`,
        [planTier, customerId]
      );
    }
  }
  if (drift.length > 0) {
    await sendAlert(`Reconciliation drift: ${drift.length} accounts`, drift);
  }
}

reconcile().catch((err) => {
  console.error(err);
  process.exit(1);
});

The first time you run this on a 6-month-old codebase, you will find drift. I've never seen this fail to surface at least one mismatch. Log it loudly, repair the divergence, notify yourself.

The reconciliation cron is the safety net that catches whatever the previous three patterns miss: the 3-day Stripe retry window that expired during a holiday, the customer who used the Customer Portal to switch plans while your webhook handler was returning 500, the silent failure that nobody noticed because your error tracking is muted on weekends.

For GitHub, Twilio, Postmark and the rest, the same shape applies: if the provider has a list API for the resources its webhooks describe, you can reconcile. Fetch the truth, diff against your DB, repair, alert.

What I built (and why this matters)

I run Belmo, a managed PaaS for developers, agencies, and non-tech founders. I built it because I was tired of solving the same shape of problem on every client engagement: a 3-process app (web service, worker, scheduled job) usually requires a Kubernetes setup or a $200/month bill for that to work reliably. Belmo gives you all three primitives on the €35/month Pro tier, with a free tier that does not sleep.

This article exists because the AI log monitoring in Belmo flagged exactly this pattern for me last month: a client's webhook worker was silently 500ing on a specific event type for 4 hours before our Telegram alert fired. The pattern detection caught the cluster of "stripe_handle_failed" log lines, classified them as a hot Sentry fingerprint, and pinged me. I want every founder to have that net, even the ones who never become customers.

That's the only Belmo mention in this article. The patterns above stand on their own.

What to do tonight, regardless of platform

If you have not done these seven things, do them before you sleep:

Open your webhook handler. Move every database write that isn't "insert the raw event" out of the HTTP request. The HTTP handler should be 20 lines or less.
Add a unique constraint on the Stripe event ID column (or whichever upstream ID you use). If you cannot enforce idempotency at the DB layer, you do not have it.
Schedule a daily reconciliation cron against your payment provider's API. Even if it is a 30-line script that just logs drift, you need the visibility.
Add monitoring on webhook 5xx responses. Stripe shows this in their dashboard, but it is a polled view. Push it to whatever alerts you actually read (Telegram, Slack, Discord, email at minimum).
Test the failure path: stop your worker for 10 minutes, fire a test event from the Stripe CLI, confirm it ends up in the dead-letter state correctly and not lost. If you have never tested this, you do not have it.
Add a "dead" status alert. When any event moves to dead, page yourself. These are real customers in a bad state.
Audit how your post-checkout redirect handles the race condition with the webhook. If the user hits the success page before your webhook has fired, what do they see? "Upgrade pending" is correct; "Welcome to Pro" with no Pro access is the dispute path.

That list takes an evening if you don't have any of it. Mine took half a Saturday on a small Express app, including the reconciliation cron.

The closing question

What's the worst webhook failure you've shipped? I'm collecting horror stories for a follow-up post on the rarer edge cases (idempotency keys colliding across test mode and live mode is one I lost a weekend to). Drop yours in the comments and I'll write up the patterns that fix them. The chargeback that prompted this article was a "we'll think about it later" hole in pattern 3, and "later" turned out to be a $64 mistake plus three sleepless days. I'd rather argue about edge cases now than wake up to another DM at 11pm.

Previous posts in this series:

Your indie SaaS has zero working Postgres backups. Here's the 20-minute fix (and the drill you need to run before you sleep tonight).

Chalom Ellezam — Thu, 14 May 2026 08:05:30 +0000

I'm a senior backend tech lead in Paris and I run Belmo, a managed PaaS. I'll mention HG exactly once near the end. Everything else in this article works on any platform you ship on.

A founder DMed me last month about a Render Postgres instance that had been humming along for nine months without a hiccup. Stripe charges going through, customers happy, MRR pushing past €4k. He wanted my opinion on something else, but during the call I asked how often his database backed up. He paused, opened the Render dashboard, clicked Postgres, then Backups, and saw exactly one snapshot from the day he provisioned the instance.

This is not rare. I review side projects and small SaaS stacks every week, and "zero working backups" is the single most common operational bug in the deployment of someone who shipped fast and learned to operate later. It's also the cheapest bug in the world to fix. You can wire up a working strategy in twenty minutes. The reason most solo founders don't is that the canonical advice (configure AWS RDS, set up S3 lifecycle policies, write a Lambda, install Datadog) is written for a team of four. So we're skipping all of that.

The lie we tell ourselves about "managed" databases

Almost every managed Postgres provider has a "backups" tab. Render does. Supabase does. Railway does. Neon does. AWS RDS does. People glance at this tab once, see the word "automatic," and assume the problem is solved.

It is not solved, for three reasons.

First, the default retention window on free and hobby tiers is much shorter than founders think. Render's hobby Postgres retains daily snapshots, but only for a few days, and the snapshots stop the moment you exceed plan limits. Supabase free retention covers a single day on the current tier. Neon has branching but no automatic point-in-time recovery on the free plan past 24 hours. None of this is hidden, but I have not yet met an indie founder who has read the fine print on the plan they signed up for in 2024.

Second, "managed" backups are usually stored on the same vendor as your live database. If your account is suspended (billing failure, terms-of-service trigger, a misunderstanding on a 2am support ticket), your backups vanish with the rest of the instance. I have watched this happen twice in two years. Both founders had paying customers. Both lost data they would have paid me five figures to recover. There was nothing to recover.

Third, the restore path is almost never tested. A snapshot you cannot restore from in under fifteen minutes is not a backup. It is hope.

Working backups for a solo founder satisfy three properties: they run automatically, they live somewhere your primary vendor cannot touch, and you have personally restored from them at least once.

What a real backup strategy looks like for a 1-person SaaS

You want three things in place. None of them require a DevOps hire.

A nightly logical dump of your production database, pushed to an external store. "Logical" means pg_dump, not a filesystem snapshot. Logical dumps are slower than snapshots, but they are portable: you can restore them onto any Postgres of compatible major version, on any provider, from any laptop. For a SaaS with a database under 10 GB (which is most indie SaaS in their first two years), this is the right primitive.

A retention policy of at least thirty days, daily. For most products, the urgent question is not "what was the data five minutes ago" (that's what your live database is for). The question is "what did the data look like before the migration I shipped on Tuesday that quietly nuked the users.timezone column." Thirty daily snapshots covers nearly every realistic incident I've seen in fifteen years. If you need point-in-time recovery within seconds, you are past the threshold of this article and you should pay an ops person.

A restore drill, run once, written down. The single most useful operational habit I've ever developed is restoring a backup to a scratch database, running a quick query against it, and timing how long the whole thing took. The first time I did this on a project at koodos labs back in NYC, the restore "worked" but the encoding settings on the receiving instance differed enough that a couple of emoji-heavy columns came back mangled. Better to find that out on a Sunday afternoon than during an incident.

The 4-line cron job that gets you 80% there

Here is the smallest setup that satisfies all three properties. Drop it on any host with cron and pg_dump available, plus credentials to write to one external object store (Backblaze B2, Cloudflare R2, Wasabi, or AWS S3 if you must).

#!/usr/bin/env bash
set -euo pipefail

TS=$(date -u +%Y%m%d-%H%M%S)
FILE="/tmp/backup-${TS}.sql.gz"

pg_dump "$DATABASE_URL" --format=plain --no-owner --no-privileges \
  | gzip -9 > "$FILE"

rclone copyto "$FILE" "b2:my-bucket/postgres/${TS}.sql.gz"

rm "$FILE"

Four substantive lines. Put it in /etc/cron.daily (or your platform's scheduled-jobs feature), set DATABASE_URL and the rclone config in env vars, and you have a daily off-vendor backup. rclone is one binary, no dependencies, and it talks to virtually every cloud storage provider with the same syntax.

For retention, give the bucket a lifecycle rule: keep objects for 30 days, then delete. Cloudflare R2 and Backblaze B2 both have these in their UI under "Bucket settings." You don't need to write code for the rotation, just configure it once.

What this setup does not do: it does not protect you against a backup that is silently broken (a dump that says "succeeded" but is missing tables because of a permission issue, or a gzip that truncated because the disk filled up). The simplest defense is a size sanity check. If today's compressed dump is dramatically smaller than yesterday's, something is wrong, and you want a Telegram message before you find out the hard way.

Here is the version I actually use, which adds that check.

#!/usr/bin/env bash
set -euo pipefail

TS=$(date -u +%Y%m%d-%H%M%S)
FILE="/tmp/backup-${TS}.sql.gz"
LAST_SIZE_FILE="/var/lib/backups/last-size"

pg_dump "$DATABASE_URL" --format=plain --no-owner --no-privileges \
  | gzip -9 > "$FILE"

SIZE=$(stat -c%s "$FILE")
LAST=$(cat "$LAST_SIZE_FILE" 2>/dev/null || echo "$SIZE")
RATIO=$(awk -v a="$SIZE" -v b="$LAST" 'BEGIN{print a/b}')

if awk "BEGIN {exit !($RATIO < 0.8)}"; then
  curl -s "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
    -d chat_id="${TG_CHAT}" \
    -d text="Backup shrank to ${RATIO}x of yesterday. Investigate."
fi

echo "$SIZE" > "$LAST_SIZE_FILE"
rclone copyto "$FILE" "b2:my-bucket/postgres/${TS}.sql.gz"
rm "$FILE"

If you don't have Telegram alerting wired up yet, see article #4 in this series. The Telegram piece takes five minutes and is the thing I'd put on every project before I'd install Sentry.

A note for the Postgres pedants: --format=plain is intentional. Custom format (-Fc) is faster and smaller, and pg_restore is more flexible against it, but plain SQL is human-readable. I have personally done a partial restore by opening a backup in vim and copying out the rows I needed. You will not regret choosing plain text the first time you need it.

Restoring is the test you actually need to run

This is the step almost everyone skips. It is the step that turns "I have backups" into "I have working backups." They are not the same thing.

Once a quarter, do this:

# 1. Pull yesterday's backup down
rclone copyto b2:my-bucket/postgres/<yesterday>.sql.gz /tmp/restore.sql.gz

# 2. Spin up a scratch Postgres locally
docker run -d --name scratch-pg \
  -e POSTGRES_PASSWORD=test \
  -p 5433:5432 \
  postgres:16

# 3. Restore
gunzip -c /tmp/restore.sql.gz | psql -h localhost -p 5433 -U postgres -d postgres

# 4. Sanity-check a row count
psql -h localhost -p 5433 -U postgres -d postgres \
  -c "select count(*) from users;"

Time it. Write the elapsed minutes down. The number you want in your head is your recovery time: how long from "database is gone" to "product is back up." For most indie SaaS the answer should be under an hour, and most of that should be data transfer. If it takes you four hours to figure out how to restore, your backups are doing less for you than you think.

The first time you run this drill, you will hit one of these problems. The dump is missing a schema you didn't know about (Postgres has public plus often a pg_catalog, plus extension schemas like pgvector or pg_trgm). The Postgres major versions are incompatible because you upgraded the live instance and forgot the dump tooling. The gunzip produces a corrupted file because last night's S3 upload timed out and you only stored the truncated piece. The role definitions clash because you used --no-owner but a function depends on a specific role.

Every one of those is easier to debug on a Sunday afternoon than at 3am during an incident.

The three mistakes I see every single week

The first is using only the vendor's built-in backups. We covered this above. If your provider's account suspends, your billing card expires, or the region has a bad day, the backups go with the database. Off-vendor storage is not optional.

The second is backing up only the database. Indie SaaS often has uploaded user files (avatars, generated PDFs, CSV exports, AI-generated images) sitting on the same disk as the app, or in the vendor's local volume. If you are already using S3-compatible object storage for uploads, you are fine: those buckets have their own durability and you can mirror them with rclone sync on the same schedule as your DB. If you are storing uploads on the dyno's local disk, you have unbacked-up state, and the day the dyno is recycled you discover this. Move that to object storage first.

The third is the one I want to spend a paragraph on, because it bites people who think they did everything right. If your app stores PII encrypted at the column level (which it should, especially under GDPR), the database dump is useless without the encryption key. The key lives in an env var or a secrets manager. Back that up too. Store it separately, in a password manager or a dedicated secrets vault, and write down the recovery procedure. I lost an afternoon to this exact configuration drift on a client project a few years ago. The database came back fine and we still couldn't read half the columns.

What I built

I run Belmo because I spent fifteen years (Oney, BeReal, Ringover, koodos labs, agency contracts) writing variations of the cron above for every new project. At some point I got tired of rebuilding the same scaffolding and shipped a managed PaaS where daily off-vendor Postgres backups, encrypted env vars, and AI-driven Telegram alerts (including the "your backup shrank" pattern from above) are part of the default experience. EU and US data centers, GDPR, ISO 27001, the routine. The free tier doesn't sleep. That's the only mention you'll get. Everything in this article works on Render, Railway, Fly.io, Supabase, a raw VPS, or your own Kubernetes cluster.

What to do tonight regardless of which platform you use

Five steps, in order. Block off an hour.

Step one. Pull your live database with pg_dump from your laptop right now. Time it. If you can do it at all, you have a baseline. If you cannot (credentials are wrong, network rules block you, you've forgotten the password to the live DB role), fix that first. You need this skill to exist before you automate anything.

Step two. Create a bucket on Backblaze B2 or Cloudflare R2. Both have free tiers that cover a 10 GB SaaS for years. Generate an access key, store it in your password manager, and verify you can rclone copyto a test file into it.

Step three. Wire up the cron script from this article. Put it on whatever scheduler your platform exposes (Render scheduled jobs, Fly cron, GitHub Actions on a schedule:, your PaaS's on-demand script feature, or a /etc/cron.daily entry on a VPS). Run it once manually. Confirm the file lands in the bucket.

Step four. Set a lifecycle rule on the bucket: retain for 30 days, delete after. This step takes 90 seconds in the B2 or R2 UI. Without it, you'll pay for storage forever and the bucket will become a haystack.

Step five. Block off ninety minutes next weekend for the restore drill. Restore yesterday's dump to a scratch Postgres, run a row-count query, write down the elapsed time. That number is your recovery time objective. Now you can answer the customer who asks "what happens if you lose my data" without lying.

If you only do step one tonight, you've already moved the needle. Most founders haven't.

One question

I'd be curious from anyone reading: have you ever actually restored from a backup in production, not as a drill but because something went wrong? What broke in the restore that you didn't expect? The interesting failure modes are not in the docs, and I'd love to read them in the comments.

Previous posts in this series:

Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep.
I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.
Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.
Telegram alerts for any production app: a 5-minute setup (no SaaS, no signup, just curl)
How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)
I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).
The Claude Code → production checklist: 15 things that aren't obvious until they bite you

The Claude Code production checklist: 15 things that aren't obvious until they bite you

Chalom Ellezam — Tue, 12 May 2026 12:14:16 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo. This list applies to any platform; Belmo happens to handle a few of these for you automatically, which I'll flag honestly when relevant.

I've helped about a dozen non-technical founders take their first Claude Code MVP from localhost:3000 to a real production URL in the last six months. They are much better at shipping than the same founders would have been two years ago.

But the same 15 things keep biting them in the first two weeks after launch. Almost none of these are about the code being wrong. They are about production being a different environment with its own rules, rules nobody warned anyone about because everyone assumed you already knew them.

This is the checklist I now send to every founder before they go live. If you went live in the last 30 days and didn't go through it, you almost certainly have at least four of these issues right now.

1. Your `.env` file is in your git history

Even if your current code has .env in .gitignore, check git history:

git log --all --full-history -- .env
git log --all --full-history -- .env.local

If anything shows up, your API keys were exposed at some point. They are still exposed, because git history is forever. Rotate every key in that file. Today. Yes, even if the repo is private. Future you who makes the repo public for an open-source moment will thank present you.

2. You have one set of API keys for dev and prod

Same OPENAI_API_KEY, same STRIPE_SECRET_KEY, same SENDGRID_API_KEY in your laptop and on the production server. The first time you accidentally run a test script that fires 500 emails or charges 200 cards, you'll wish you had a *_DEV and a *_PROD. Make separate keys per environment. Today.

3. Your Stripe webhook is unsigned

When Stripe POSTs to /api/webhooks/stripe, you should verify the signature header before trusting the payload. If your code just reads req.body.amount and credits the user's account, anyone on the internet can hit that URL with fake events and give themselves credits.

The fix is three lines:

const sig = req.headers['stripe-signature'];
const event = stripe.webhooks.constructEvent(req.rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET);
// Now use event.type, event.data — verified.

Required reading: Stripe's webhook signature docs.

4. You're using Stripe test keys in production

Your STRIPE_SECRET_KEY starts with sk_test_... instead of sk_live_.... Real payments hit Stripe's test environment, which... doesn't charge anybody. You launch, you celebrate the first sale, three days later you realize Stripe has $0 from you.

Same with STRIPE_PUBLISHABLE_KEY and the frontend pk_test_* vs pk_live_*. Match them. Double-check after every deploy in the first week.

5. Your database has no backup strategy

"I'll set up backups later" is a sentence I have heard about 100 times. Approximately zero of those people set up backups later. Then someone (often Claude) runs a migration that drops a table, and the conversation is over.

Most managed databases (Supabase, Neon, managed Postgres on any PaaS) have automatic daily backups built in but only if you turn it on. Click around your database dashboard now. If you don't see "Backups enabled," fix it before reading item 6.

For self-hosted: pg_dump to S3 / Cloudflare R2 nightly via a cron. Test the restore. Once. The 5 minutes you spend testing is the difference between "we recovered" and "we lost everything."

6. You have no rate limiting on AI endpoints

You have a /api/chat route that calls OpenAI. Someone (a scraper, a bored teen, your competitor) discovers it and hits it in a for loop. By the time you notice, your OpenAI bill is up by $400 and the abuser has stopped.

Even a stupid rate limit is much better than no rate limit:

// Crude but works
const ipHits = new Map();
app.post('/api/chat', (req, res) => {
  const ip = req.ip;
  const now = Date.now();
  const hits = ipHits.get(ip) || [];
  const recentHits = hits.filter(t => now - t < 60_000);
  if (recentHits.length >= 10) return res.status(429).send('slow down');
  recentHits.push(now);
  ipHits.set(ip, recentHits);
  // ... your real handler
});

10 calls/minute per IP. Most legitimate users won't hit it. Most abusers will. For real production, use a library (express-rate-limit, slowapi, etc.) with Redis-backed counters.

7. CORS is wide open

You have Access-Control-Allow-Origin: * in your headers or cors({ origin: '*' }) in your Express setup. For a public read-only API, fine. For anything with auth, this means any random website can make authenticated requests as your logged-in users.

Set origin to your specific frontend domain. If you need both https://yourapp.com and https://www.yourapp.com, use an allowlist:

const allowed = ['https://yourapp.com', 'https://www.yourapp.com'];
app.use(cors({ origin: (origin, cb) => cb(null, !origin || allowed.includes(origin)) }));

8. You haven't set up error tracking

Sentry takes 25 minutes to install. Until you have it:

Your users find bugs before you do
You spend hours guessing what broke from screenshots
You miss the bugs that don't generate user complaints (and there are a lot of those)

Install it tonight. Free tier covers 5K errors/month, plenty for any startup under 10K users.

npm install --save @sentry/nextjs   # or @sentry/node, @sentry/python, etc.
npx @sentry/wizard -i nextjs        # follows a guided setup

9. Your app ships source maps to production

Source maps make stack traces readable, but if they're served publicly, anyone can open Chrome DevTools and read your original (TypeScript / unminified) code. This includes your API logic, your prompts to OpenAI, your business rules.

For Next.js:

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
};

Upload source maps to Sentry instead (so YOU can debug stack traces) and exclude them from the public bundle.

10. You have no `/healthz` endpoint

Most hosting platforms periodically ping a health endpoint to know if your app is alive. If you don't have one, the platform pings your homepage, which loads your full app stack including AI calls, which is slow and expensive.

Add one line:

app.get('/healthz', (_req, res) => res.status(200).send('ok'));

Configure your hosting platform's health check to point at /healthz. Cheap, fast, useful.

11. Your DNS TTL is too high

Most domain registrars default to a 24-hour or 4-hour TTL (Time To Live) on DNS records. This means when you change your domain to point at a new host, browsers and ISPs cache the old DNS for up to 24 hours.

Before any DNS migration, log into your registrar (Namecheap, OVH, Cloudflare) and set TTL to 300 seconds (5 minutes). Wait one TTL period. Then make your changes. Propagation will be minutes, not hours.

Do this before you need to migrate, not the day of.

12. Your runtime version isn't pinned

Claude Code generates code targeting whatever Node / Python / Ruby version it's currently aware of (often the latest). Your hosting platform might run an older default. Result: subtle bugs that work on your laptop and break in prod.

For Node, in your package.json:

{
  "engines": {
    "node": "20.x"
  }
}

For Python, create runtime.txt:

python-3.11.7

For Ruby, .ruby-version:

3.2.2

Pin once. Forget about it. Your future self never debugs "works on my laptop" again.

13. Server secrets are in your frontend bundle

In Next.js, environment variables prefixed with NEXT_PUBLIC_ are sent to the browser. If you accidentally name your server secret NEXT_PUBLIC_STRIPE_SECRET_KEY, you have just published it to every user's Chrome.

Rule:

NEXT_PUBLIC_* → safe for the browser (analytics IDs, Stripe publishable keys, feature flags)
Any actual secret → no prefix. Server-only.

Same idea in Vite (VITE_*), Create React App (REACT_APP_*), Astro, etc. Audit your .env for any "PUBLIC" variable that shouldn't be.

14. You have no monitoring on cron jobs

You set up a nightly job at 0 3 * * *. It worked for the first three days. It hasn't run in two weeks because of a node_modules issue you didn't notice. You only realize when you check the database and see no new data.

Two ways to know your crons are running:

Easy way: every cron pings a service like healthchecks.io (free for solo use). If the ping doesn't arrive within the expected window, it emails you.

0 3 * * * /opt/myapp/nightly.sh && curl -fsS -m 10 https://hc-ping.com/<uuid>

Harder way: hosted platforms with built-in cron observability. Belmo does this via its AI monitoring layer (more on that at the end). Render and Railway expose cron logs but you have to remember to look.

15. Your app crashes silently on startup, restarts forever

A crash on boot looks like this: your platform starts your container, your app throws an uncaught exception within 2 seconds, platform restarts, repeat. Externally, your domain just returns 503s.

If you don't have a process.on('uncaughtException') handler that logs to your error tracker AND alerts you on Telegram/Slack/email, this can go on for hours before you notice.

Minimum viable setup:

process.on('uncaughtException', (err) => {
  console.error('FATAL:', err);
  // Optionally: send to Sentry, post to Telegram, etc.
  process.exit(1); // let the platform restart cleanly
});

Then make sure your hosting platform's health check is configured (item 10), so when crashes happen it actually stops trying to restart endlessly.

The faster path through this list

Some of these are handled for you on managed PaaS platforms:

Belmo (full disclosure: I build it): encrypted env vars (so item 13's blast radius is smaller if you misname), AI-monitored crash loops (so item 15 pings you on Telegram automatically), built-in cron job monitoring with the same Telegram alert (item 14). The list of what you still need to do yourself remains long though: items 1–4 (key hygiene), 5 (backups), 6–7 (rate limiting + CORS), 9 (source maps), 11 (DNS), 12 (runtime pinning). The platform can't fix code-level decisions.
Render / Railway / Fly.io: similar pattern. Some items (env vars in dashboard, basic process restart logic) are handled. The code-level items remain yours.
VPS + Coolify or Dokku: you handle all 15 yourself. That's fine if you have the time and discipline. Most solo founders don't.

The right move is: pick a platform that handles a few of these so you can focus on the rest, then actually go through the rest.

What to do tonight, in order

Run git log -- .env (item 1) — 30 seconds. If anything appears, rotate keys immediately.
Check your Stripe key prefix (item 4) — 10 seconds. echo $STRIPE_SECRET_KEY | head -c 10. Should be sk_live_... in prod.
Add /healthz endpoint (item 10) — 2 minutes.
Add an uncaughtException handler (item 15) — 5 minutes.
Verify your database has backups enabled (item 5) — 2 minutes in your DB dashboard.

That's 10 minutes for the five most critical items. The other 10 you can do over the week.

If you build with Claude Code, this list is also a useful prompt: "Audit my repo against the following 15 items..." Claude will go through each one and tell you which apply, which don't, and give you a fix for the ones that do. It catches most of them. The audit takes maybe 15 minutes total.

What's the most embarrassing thing you've shipped to production that this list would have caught? I'm collecting horror stories for v2.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

5. How I built a Discord 'ship-tracker' bot in a weekend.

6. I migrated 12 client projects off Heroku. Here's the playbook.

I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).

Chalom Ellezam — Mon, 11 May 2026 13:18:26 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo. Six of these 12 migrations landed on Belmo. The other six went to Render, Railway, Fly.io, or back to a VPS. The playbook below works regardless of destination — it's the Heroku-side problems I want you to skip.

Since Heroku announced "sustaining engineering mode" in February 2026, I've been the person clients call when they need to get off the platform without breaking production. As of this week I've done 12 migrations — Rails apps, Django apps, Node services, Python workers — for clients ranging from 200-MAU side projects to 80K-MAU consumer apps.

If you're staring at your Heroku dashboard wondering when to leave, this is the post I wish someone had written before I started doing these.

It's two parts: the playbook (the order of operations that works), and the 7 things that bit me (the stuff nobody warns you about until you hit it at 11pm on launch night).

Part 1 — The playbook

Every migration I've done follows the same eight-step order. I've tried shuffling it. The shuffling always costs me. Just do it in this order.

Step 0: Decide the destination first

Don't start migrating until you know where you're going. Each destination changes step 4 and step 7 significantly.

Render: closest to old Heroku ergonomics, web service sleeps on free tier, Postgres is solid
Railway: best DX for small projects, usage-based pricing surprises at scale, Postgres reliability has been variable
Fly.io: best if you need multi-region, requires a fly.toml file
Belmo: managed PaaS, EU + US, AI monitoring built in, predictable pricing
AWS / GCP: only if you have a real DevOps person on the team
VPS + Coolify/Dokku: cheapest, you maintain the server

For the rest of this playbook I'll be platform-agnostic except where it matters.

Step 1: Inventory what's actually running

Before touching anything, list every dyno, every add-on, every config var, every scheduled job.

heroku ps --app yourapp        # web + worker dynos
heroku addons --app yourapp     # databases, redis, monitoring, etc.
heroku config --app yourapp     # env vars (don't paste this in Slack)
heroku features --app yourapp   # any legacy/labs features still on
heroku scheduler:jobs --app yourapp  # if using Heroku Scheduler

Pipe these into a markdown file in your repo (MIGRATION.md). You will need to refer to it 6 times.

Step 2: Provision the destination

On the new platform, create everything that needs to exist before the cutover:

The web service (don't deploy real code yet — a placeholder is fine)
Workers if you have them
Database (always Postgres for me; we'll cover the dump-restore in step 5)
Redis if you have Sidekiq/BullMQ
Object storage if you use S3-equivalent
Any external API webhooks (you'll need to update their target URLs in step 7)

Goal at end of step 2: every "thing" exists on the new side, empty.

Step 3: Copy env vars carefully

This is where every migration gets a paper cut. Heroku's heroku config output looks like this:

DATABASE_URL: postgres://user:pass@host:5432/db?sslmode=require
REDIS_URL:    redis://...
RAILS_MASTER_KEY: ...
STRIPE_SECRET_KEY: sk_live_...

Three things to watch:

DATABASE_URL will need to change to the new DB's URL. Don't paste the Heroku one.
Watch the trailing ?sslmode=require — this is the #1 silent migration killer (more on this in Part 2).
Heroku auto-generates PORT for you; on most platforms you do too, so don't manually copy it.

Step 4: Deploy code to the new platform — get "hello world" working

Push your code to the new platform. Don't migrate the database yet. Just confirm the platform can build your code and your /healthz endpoint returns 200.

If you have a deploy config file (render.yaml, fly.toml, Belmo.yml, whatever), put it in your repo BEFORE the migration and merge it. Don't be discovering it works at 11pm.

Step 5: Database migration (the scary part)

Backup → restore. The commands are basically the same on every platform:

# From Heroku
heroku pg:backups:capture --app yourapp
heroku pg:backups:download --app yourapp --output /tmp/dump.tar

# To new platform (psql connection details from the new DB)
psql -h NEW_HOST -p NEW_PORT -U NEW_USER -d NEW_DB \
  -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"

pg_restore --verbose --no-owner --no-acl \
  -h NEW_HOST -p NEW_PORT -U NEW_USER -d NEW_DB /tmp/dump.tar

Then verify with row counts, every single table:

SELECT 'users' AS table_name, COUNT(*) FROM users
UNION ALL SELECT 'posts', COUNT(*) FROM posts
UNION ALL SELECT 'orders', COUNT(*) FROM orders;

Compare to Heroku. If anything mismatches, stop, investigate, don't proceed.

Step 6: Put Heroku in maintenance mode + flip DNS

heroku maintenance:on --app yourapp
# users see a "we'll be back" page

Then update your DNS provider (Namecheap, OVH, whatever) to point at the new host. Set TTL low (300 seconds) before this if you remember — DNS propagation will go faster.

Step 7: Final dump + restore

Yes, dump the database again. Heroku has been writing data for the last few hours while you set up. Do a fresh capture, restore on the new side. Then row-count verify again.

Yes, this means downtime equal to the dump-restore time. For most apps under 5GB, this is 5–15 minutes. Schedule the migration window.

Step 8: Reroute external webhooks, then drop maintenance mode

Anything that calls into your app from outside needs its target URL updated to the new host:

Stripe webhooks
SendGrid event webhooks
OAuth callback URLs (Google, GitHub, Slack)
Custom integrations
Cron jobs hitting your /api/... endpoints from external services

Then heroku maintenance:off. Then watch your logs for 10 minutes straight. If the logs are quiet and your /healthz is green, you're done.

Part 2 — The 7 things that bit me

This is the part nobody warns you about. Every one of these has cost me at least 45 minutes of debugging at least once.

Bite 1: The `heroku_ext` schema doesn't exist anywhere else

Heroku installs Postgres extensions in a special heroku_ext schema (not public). When you pg_restore to a non-Heroku Postgres, the restore tries to install extensions in heroku_ext and fails:

pg_restore: error: could not execute query: ERROR:  schema "heroku_ext" does not exist

The restore often appears to complete despite the error, but the extensions (uuid-ossp, unaccent, pg_trgm, etc.) aren't installed. Then your app boots and gets a function uuid_generate_v4() does not exist 500 error in production.

Fix: after restore, recreate the extensions manually:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "unaccent";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";

List of likely-needed extensions: heroku pg:psql --app yourapp -c "SELECT extname FROM pg_extension;" before you migrate.

Bite 2: `pg_stat_statements` is enabled by default on Heroku, often not elsewhere

If you have any internal slow-query monitoring (e.g. PgHero, a custom admin dashboard), it queries pg_stat_statements. On the new platform this extension is often not enabled by default. Your slow-query dashboard silently shows zero queries.

Fix: enable it on the new platform. On Render/Railway/Belmo it's a one-line config flag. On a VPS with your own Postgres, edit postgresql.conf:

shared_preload_libraries = 'pg_stat_statements'

Then CREATE EXTENSION pg_stat_statements;.

Bite 3: Heroku's `DATABASE_URL` bakes in `sslmode=require`

Heroku's connection string format always includes ?sslmode=require. Most apps rely on this being implicit. When you move, some platforms don't add it by default, and your Rails / Django / Node app starts logging cryptic SSL errors at higher load (when the connection pool churns):

PG::ConnectionBad: SSL connection has been closed unexpectedly

Fix: explicitly add ?sslmode=require to your new DATABASE_URL. Or set PGSSLMODE=require as an env var. Diff the connection strings character-by-character before flipping traffic.

Bite 4: Scheduled jobs run on different time zones

Heroku Scheduler runs jobs in UTC. Some platforms default to UTC, some default to the platform's region timezone, some default to whatever timezone the cron entry doesn't specify.

If you have a 0 9 * * * job that ran at 9am UTC on Heroku, and you migrate to a platform that interprets it as 9am local-time-of-some-California-datacenter, your "daily report at 9am Paris time" now runs at 6pm.

Fix: always explicitly check the new platform's cron timezone before migrating. Most modern platforms (Render, Railway, Belmo) are UTC. AWS EventBridge defaults to UTC. Older or self-hosted setups vary.

Bite 5: Heroku's `DYNO` env var doesn't exist anywhere else

Heroku sets DYNO=web.1 or DYNO=worker.1 automatically. Some apps use this to determine "am I a web process or a worker?" so they can skip certain initialization. After migration, DYNO is unset, and your worker process tries to bind to a port (because the "am I web?" check defaults to true).

Fix: grep your codebase for process.env.DYNO, ENV["DYNO"], os.environ.get('DYNO'). Replace with explicit env vars you set per process (PROCESS_TYPE=web vs worker).

Bite 6: Heroku Postgres "follower" replicas don't survive

If you used Heroku Postgres followers (read replicas) for analytics queries, those don't migrate. The new platform may or may not have a managed replica option, and the connection string format is always different.

Fix: if you don't use the replica heavily, just point all queries at primary for the first week post-migration. Then add a replica on the new platform if needed. Don't try to bring the replica online during the migration itself.

Bite 7: Buildpacks vs Docker — your build will behave subtly differently

Heroku auto-detects your stack via buildpacks (e.g. heroku/python, heroku/ruby). Some new platforms also use buildpacks (Render uses Nixpacks, Railway uses Nixpacks). Some require a Dockerfile.

Even when both use buildpacks, the specific buildpack version differs. I've seen the same requirements.txt install Python 3.11.7 on Heroku and Python 3.12.1 on Render — and then a library breaks because Python 3.12 deprecated something.

Fix: pin your runtime version explicitly. For Python, that's a .python-version or runtime.txt. For Ruby, that's .ruby-version. For Node, that's "engines": { "node": "20.11.x" } in package.json.

The full migration timeline I quote clients

For a "small to medium" Rails or Django app (1 web service, 1 worker, 1 Postgres < 5GB, < 20 env vars):

Step 0 (decide destination): 1–3 days (mostly waiting for client approval)
Step 1–4 (prep): half a day of focused work
Step 5 (DB migration dry-run): 1 hour
Step 6–8 (cutover window): 30–60 minutes with the team on standby

Total: roughly 2–3 hours of execution time in a 1-week calendar window. The week is for sanity, not because the work takes that long.

If anyone quotes you "we'll migrate Heroku in 30 minutes," they haven't done it. There's always something you didn't expect — most often one of the 7 bites above.

What I'd do if I were migrating today

Run the inventory (heroku ps, addons, config, scheduler:jobs) and put it in a markdown file today. You'll need it whether you migrate this month or in 6 months.
Pick a destination that fits your team's operational maturity. If you don't have a DevOps person, pick a managed PaaS. If you have someone who already runs Kubernetes, you have more options.
Pin your runtime versions in your repo before the migration. This is the cheapest insurance policy.
Do one dry run of the database migration to a throwaway DB on the new platform. Verify row counts. Then do the real one later.
Schedule the cutover for a Tuesday or Wednesday morning, not a Friday. If something breaks, you want a full work week to fix it.

A note on the platform I run

If you're picking a destination and you want one that ships with the operational stuff (Telegram alerts, log-pattern detection, EU data center, predictable pricing), Belmo is built around exactly that. Pro tier is €35/mo for 10 services with workers and on-demand scripts included (the same primitives Heroku had with worker: dynos and Heroku Scheduler). Free tier never sleeps.

If you pick another destination, the playbook above still applies — just translate "step 4: deploy code" to whatever that platform's deploy flow is.

Closing

Heroku is in maintenance mode, not gone. Your app will keep working there. But every month you delay migrating, you're betting that nothing breaks on a platform that's stopped investing in fixing things. That's not crazy in 2026. It just gets less crazy with time, not more.

Whenever you do migrate, the order of operations matters more than which destination you pick. Pick the order. Execute Tuesday morning. Watch the logs for 10 minutes. Then take Wednesday off — you've earned it.

What's the dumbest thing that broke during your migration? I'm collecting these for v2 of this post.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

5. How I built a Discord 'ship-tracker' bot in a weekend.

How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)

Chalom Ellezam — Fri, 08 May 2026 17:54:27 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo. This bot runs on Belmo's Pro tier — but the architecture (web service + worker + scheduled job) works on any platform that supports those three primitives. I'll point out where each piece runs.

I co-run a small Discord community for indie founders building dev tools. About 220 members, mostly early-stage SaaS people, lots of Claude Code / Cursor enthusiasts. Every Monday I used to manually scroll through the previous week's #i-shipped channel and write a digest message: "this week we shipped X, Y, Z."

It took 30 minutes every Monday morning. After 5 weeks of it I did the math — 30 min × 52 weeks = 26 hours a year of me doing what a bot could do better. So one Saturday I built ShipTrack, the bot that's been keeping my Mondays free for 6 months now.

This is the build log. It's mostly about an architecture decision (3 separate processes instead of 1) that turned out to be the difference between "bot keeps crashing" and "bot just works."

What the bot does

Three things, in order of complexity:

Listens for the /ship slash command. When a member runs /ship "Launched my AI todo app — feedback welcome: link.com", the bot logs the launch into a database and reacts with 🚀 in the channel.
Tracks #i-shipped channel messages. When anyone posts in that channel (without slash command), the bot detects launch-shaped content (heuristic: contains a URL + at least one of "shipped", "launched", "live"), logs it, reacts.
Posts a weekly digest every Monday at 9am UTC. The bot pulls all launches from the last 7 days, formats them into a nice list, and posts it to #announcements with @-mentions of the founders.

That's it. Three things. But they map to three completely different kinds of computation, which is where v1 went wrong.

v1: the naive setup that crashed in 15 minutes

I started simple. One Node.js file. node bot.js. Deploy to a Render free web service. Done in 30 minutes.

It worked on my laptop. It worked for the first 14 minutes after deploy. Then Render's free tier put the service to sleep due to no incoming HTTP traffic — and a Discord bot doesn't get HTTP traffic by default. It maintains a long-lived WebSocket connection to Discord's gateway. Render couldn't see that traffic. To Render, my bot was idle. So Render killed it.

When the bot came back from sleep 30 seconds later, it tried to reconnect to Discord's gateway. Discord saw two sessions for the same bot. The old session got disconnected with a 4008 Reconnect and the new one inherited some weird state. Members started seeing the bot react to messages twice. Slash commands timed out.

This is the kind of bug that takes a long time to diagnose if you've never seen it before, because everything looks fine in your logs. There's no error, just slightly wrong behavior. I wasted 4 hours.

Why Discord bots are weirder than they look

The thing nobody tells you when you start: a Discord bot has two completely different communication channels with Discord's servers, and they have totally different operational requirements.

Channel 1: the gateway (WebSocket, persistent).

The bot opens a WebSocket to wss://gateway.discord.gg
Stays open forever
Receives every event in real time (member joined, message posted, reaction added)
Sends heartbeats every 41.25 seconds
If the connection drops for >60 seconds, you have to fully re-authenticate and resync state

Channel 2: slash commands (HTTP, on-demand).

Discord POSTs to YOUR endpoint when a user runs a slash command
You have 3 seconds to respond or Discord shows "interaction failed" to the user
Public HTTP endpoint with signed payload verification

These two channels don't fit on the same kind of host. The gateway needs always-on. The slash command webhook needs public HTTPS that wakes up fast. Most "deploy your Node app" flows assume one or the other, not both.

v2: three processes, three responsibilities

The architecture I landed on has three pieces:

┌──────────────────────┐    ┌──────────────────────┐    ┌──────────────────────┐
│  WEB SERVICE          │   │  WORKER               │   │  SCHEDULED SCRIPT     │
│  HTTPS endpoint       │   │  Always-on process    │   │  Runs Monday 9am UTC  │
│  Slash command webhook│   │  Discord gateway      │   │  Generates weekly     │
│  /api/discord/interact│   │  WebSocket connection │   │  digest               │
└──────────────────────┘    └──────────────────────┘    └──────────────────────┘
              │                         │                          │
              └─────────────────────────┴──────────────────────────┘
                                        │
                                ┌──────────────┐
                                │  Postgres    │
                                │  (launches)  │
                                └──────────────┘

Three separate deployments, one shared database. Each process does what it's good at and nothing else.

Process 1: the web service (slash commands)

This is a tiny Express app. One endpoint. Returns under 1 second.

// web-service/server.js
import express from 'express';
import { verifyKey } from 'discord-interactions';
import { db } from './db.js';

const app = express();
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; }
}));

app.post('/api/discord/interact', async (req, res) => {
  // 1. Verify Discord signed the request
  const signature = req.get('X-Signature-Ed25519');
  const timestamp = req.get('X-Signature-Timestamp');
  const valid = verifyKey(req.rawBody, signature, timestamp, process.env.DISCORD_PUBLIC_KEY);
  if (!valid) return res.status(401).send('invalid signature');

  // 2. Discord sometimes pings to check liveness
  if (req.body.type === 1) return res.json({ type: 1 });

  // 3. Slash command — log the launch and respond fast
  if (req.body.type === 2 && req.body.data?.name === 'ship') {
    const userId = req.body.member.user.id;
    const username = req.body.member.user.username;
    const text = req.body.data.options?.[0]?.value || '';

    await db.launches.insert({
      user_id: userId,
      username,
      text,
      channel_id: req.body.channel_id,
      created_at: new Date(),
    });

    return res.json({
      type: 4,
      data: { content: `🚀 Logged your ship, ${username}!` },
    });
  }

  res.json({ type: 4, data: { content: 'Unknown command' } });
});

app.listen(process.env.PORT || 3000);

Deploy this as a normal web service. It can sleep on free tiers — Discord sends a request only when someone runs /ship, and 1 second of cold start before responding is fine. (For Belmo, I picked the Hobby tier with the always-on free guarantee anyway, but the architecture works either way.)

Process 2: the worker (gateway + reactions)

This is the long-running part. It opens the WebSocket connection to Discord and listens for messages. It can't sleep. Ever.

// worker/bot.js
import { Client, GatewayIntentBits, Events } from 'discord.js';
import { db } from './db.js';

const client = new Client({
  intents: [
    GatewayIntentBits.Guilds,
    GatewayIntentBits.GuildMessages,
    GatewayIntentBits.MessageContent,
  ],
});

const SHIPPED_CHANNEL_ID = process.env.SHIPPED_CHANNEL_ID;

client.on(Events.MessageCreate, async (msg) => {
  if (msg.author.bot) return;
  if (msg.channel.id !== SHIPPED_CHANNEL_ID) return;

  // Heuristic: contains a URL + a "shipped"-ish word
  const hasUrl = /https?:\/\/\S+/.test(msg.content);
  const hasShipWord = /\b(shipped|launched|live|released)\b/i.test(msg.content);
  if (!hasUrl || !hasShipWord) return;

  await db.launches.insert({
    user_id: msg.author.id,
    username: msg.author.username,
    text: msg.content,
    channel_id: msg.channel.id,
    message_id: msg.id,
    created_at: new Date(),
  });

  await msg.react('🚀');
});

client.on(Events.ClientReady, () => {
  console.log(`ShipTrack online as ${client.user.tag}`);
});

client.login(process.env.DISCORD_BOT_TOKEN);

Deploy this as a background worker. On Belmo this is the Pro tier worker process type — same Procfile-style declaration as Heroku's old worker: line:

# Belmo.yml (or similar config)
processes:
  bot:
    type: worker
    command: node worker/bot.js
    always_on: true

The platform keeps it running. If it crashes, it restarts. If you push new code, it gracefully reconnects. No HTTP traffic required to keep it alive — that's the whole point of a worker process type vs a web service.

Process 3: the scheduled script (weekly digest)

This one runs once a week. It's an "on-demand" script — runs, finishes, exits. Costs almost nothing.

// scripts/weekly-digest.js
import { Client, GatewayIntentBits } from 'discord.js';
import { db } from './db.js';

const client = new Client({ intents: [GatewayIntentBits.Guilds] });
await client.login(process.env.DISCORD_BOT_TOKEN);

const since = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000);
const launches = await db.launches.find({
  created_at: { $gte: since },
});

if (launches.length === 0) {
  await client.destroy();
  process.exit(0);
}

const formatted = launches
  .map(l => `• <@${l.user_id}> shipped: ${l.text.slice(0, 200)}`)
  .join('\n');

const channel = await client.channels.fetch(process.env.ANNOUNCEMENTS_CHANNEL_ID);
await channel.send({
  content: `**📦 This week we shipped (${launches.length} launches):**\n\n${formatted}`,
  allowedMentions: { users: [] }, // notify in formatting only, don't ping
});

await client.destroy();
process.exit(0);

On Belmo, this runs as an on-demand script triggered by a schedule:

processes:
  weekly-digest:
    type: script
    command: node scripts/weekly-digest.js
    schedule: "0 9 * * 1"  # every Monday at 9:00 UTC

The platform spins up an ephemeral container at the scheduled time, runs the script, captures the output, exits. You pay for ~3 seconds of compute per week. If you've ever fought with Heroku Scheduler, you'll appreciate that the script lives in your repo, version-controlled, with the same env vars as the rest of your app.

Why this architecture matters

The naive temptation is to put all three in one Node process: HTTP server + Discord client + a setInterval for the digest. Don't. Three reasons:

Crashes blast radius. If your slash-command handler throws, the gateway connection survives. If your gateway disconnects mid-deploy, the slash commands keep working. Each process is independently restartable.
Scaling differs. If you have 5,000 slash commands an hour, you scale the web service. The worker stays at 1 instance (you only need one Discord gateway connection per bot). Different processes, different scaling profiles.
Costs differ. The worker burns CPU cycles 24/7 just maintaining a heartbeat. The script runs 3 seconds a week. Putting them on the same dyno is paying always-on prices for a once-a-week task.

This three-process pattern is what you want for any bot or background-heavy service: not just Discord. Slack apps. Telegram bots. Webhook receivers with async fanout. The shape repeats.

What I learned

WebSocket gateway = needs a worker, not a web service. Free web tiers will sleep your bot. Workers don't sleep on platforms that respect the worker primitive.
Slash commands ≠ gateway. They're HTTP, you can host them anywhere, but the 3-second response cap is real. Don't do heavy work inline — log to DB, respond, finish processing async.
Use a real database, not in-memory state. I tried "just use a JSON file" for v0. Workers restart, files vanish, members lost their launch history once. Two days later I wired Postgres.
Scheduled scripts > setInterval. A setInterval in your worker tied to wall-clock time will drift, miss runs during deploys, and double-fire if you scale to 2 instances. A scheduled script run as a separate process is exactly-once, exactly-on-time.
Always reply within 3 seconds. If your slash command handler does anything slow (database query > 1s, external API), respond with a deferred response (type: 5) and follow up later via Discord's webhook.

When this architecture is overkill

If you're building a bot for 5 friends to play a Discord trivia game, run it in one Node process on your laptop. You don't need three processes. You don't need a database. You probably don't need slash commands.

The three-process pattern starts paying off when at least one of these is true:

The bot is mission-critical (community would notice if it's down).
The bot has > ~50 users sending it traffic.
You need scheduled jobs that must run even if the bot crashed yesterday.
You're deploying it on a platform where free web tiers sleep.

For ShipTrack at 220 members + weekly digest, all four were true. So the three-process setup paid for itself the first time the worker crashed at 2am and the slash commands kept working through it.

A note on Belmo

The reason I'm building on Belmo (besides the obvious "I run it" disclosure at the top) is that the three primitives I needed — web service, worker, on-demand scheduled script — are first-class citizens on the platform. Same repo, same env vars, three lines of YAML config. No fighting with Heroku Scheduler vs Heroku dynos vs Heroku one-off heroku run jobs. No spinning up separate ECS task definitions on AWS.

If you're building anything with these three shapes — and most bots, webhook receivers, and background-heavy services have them — Pro tier (€35/mo) gets you 10 services with workers and on-demand scripts included. The free Starter tier supports the web service piece if you want to wire your worker elsewhere.

What's next

ShipTrack v3 is on my todo list. I want to add:

An LLM-powered launch summary at the bottom of each digest ("this week's theme: AI productivity tools")
A /profile @user command that shows someone's all-time launches
A leaderboard of "most active shipper this quarter"

If you've built a Discord bot recently and have hard-won lessons, I'd love to hear them in the comments. Especially the embarrassing v1 stories.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

Telegram alerts for any production app — a 5-minute setup (no SaaS, no signup, just curl)

Chalom Ellezam — Mon, 04 May 2026 12:36:33 +0000

Disclosure: I'm a senior backend tech lead and I run Belmo, where Telegram alerts ship as a built-in feature. This tutorial works on any platform — it's the manual version of what Belmo does for you. Useful even if you never become a customer.

There's a hierarchy of where production alerts go, ranked by how likely you are to actually see them.

Email → 14% open rate within an hour, less at 3am.
Slack → muted in 6 of 10 teams I've seen, especially "alerts" channels.
Phone-call paging (PagerDuty, Opsgenie) → works, but $20+/user/month and overkill for solo founders.
Telegram → notification on lock screen, no setup cost, works on every phone, you'll see it.

For a solo founder or a small team, Telegram alerts hit a sweet spot: the notification is annoying enough that you'll see it, easy enough that you'll set it up, and free. After 8 years of trying every paging tool, this is what I default to for early-stage projects.

Here's how to wire it up in 5 minutes, plus what I learned about what to alert on.

Step 1: Create a Telegram bot (60 seconds)

Open Telegram, search for @BotFather, start a chat.
Send /newbot.
Pick a name. Then a username (must end in bot, e.g. myapp_alerts_bot).
BotFather replies with a token like 7234567890:AAFq.... Save it. This is your TELEGRAM_BOT_TOKEN.

That's it. The bot exists. Now we need somewhere to send messages.

Step 2: Get your chat ID (60 seconds)

You need the ID of the chat where alerts will land. Two options:

Option A — Personal alerts (just for you):

Open a chat with your new bot. Send it any message ("hello").
Visit https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in your browser.
Find the chat.id field in the JSON response. It's a number like 123456789. That's your chat ID.

Option B — Group alerts (for the team):

Create a Telegram group (or use an existing one).
Add your bot to the group.
Send any message in the group.
Visit the same getUpdates URL. The chat ID for groups is negative (e.g. -987654321).

Save the chat ID as TELEGRAM_CHAT_ID.

Step 3: Send your first alert (30 seconds)

The send API is one HTTP call. From a terminal:

curl -s -X POST \
  "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
  -d "chat_id=${TELEGRAM_CHAT_ID}" \
  -d "text=Hello from production"

Your phone should buzz immediately. If it does, the wiring is done. Now we just need to call this from your app when something interesting happens.

Step 4: Wire it into your app (3 minutes)

Node.js / TypeScript

// alerts.ts
const TG_TOKEN = process.env.TELEGRAM_BOT_TOKEN!;
const TG_CHAT  = process.env.TELEGRAM_CHAT_ID!;

export async function alert(message: string) {
  if (!TG_TOKEN || !TG_CHAT) return; // disabled in dev
  try {
    await fetch(`https://api.telegram.org/bot${TG_TOKEN}/sendMessage`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        chat_id: TG_CHAT,
        text: message.slice(0, 4000), // Telegram cap
        parse_mode: 'Markdown',
      }),
    });
  } catch (e) {
    // never let alerting crash your app
    console.error('alert failed', e);
  }
}

Use it anywhere:

import { alert } from './alerts';

process.on('uncaughtException', (err) => {
  alert(`🚨 *Uncaught exception*\n\`${err.message}\`\n\nstack:\n\`\`\`\n${err.stack}\n\`\`\``);
});

// or in business logic
if (failed > THRESHOLD) {
  await alert(`⚠️ Stripe webhook retry rate at ${failed}/min — investigate`);
}

Python

# alerts.py
import os
import requests

TG_TOKEN = os.environ.get('TELEGRAM_BOT_TOKEN')
TG_CHAT  = os.environ.get('TELEGRAM_CHAT_ID')

def alert(message: str) -> None:
    if not TG_TOKEN or not TG_CHAT:
        return
    try:
        requests.post(
            f'https://api.telegram.org/bot{TG_TOKEN}/sendMessage',
            json={
                'chat_id': TG_CHAT,
                'text': message[:4000],
                'parse_mode': 'Markdown',
            },
            timeout=5,
        )
    except Exception as e:
        # never let alerting crash your app
        print(f'alert failed: {e}')

Wire it to the unhandled exception hook:

import sys
from alerts import alert

def excepthook(exc_type, exc_value, exc_traceback):
    alert(f'🚨 *Uncaught exception*\n`{exc_type.__name__}: {exc_value}`')
    sys.__excepthook__(exc_type, exc_value, exc_traceback)

sys.excepthook = excepthook

Plain bash (great for cron jobs)

#!/usr/bin/env bash
# Save as /usr/local/bin/tg-alert
curl -s -X POST \
  "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
  --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
  --data-urlencode "text=$1" > /dev/null

Then any cron job can do:

0 3 * * * /opt/myapp/nightly-backup.sh || tg-alert "❌ Nightly backup failed at $(hostname)"

That's the whole infrastructure. You're done.

Step 5: The rate-limiting trick (the part most tutorials skip)

Here's the failure mode of every "I just wired alerts" project: a bug fires at 200/sec, your phone buzzes 200 times in 10 seconds, you mute the bot in frustration, you miss the next real alert two days later.

You need a rate limiter between your code and Telegram. The simplest one: deduplicate identical messages within a window.

Node.js — in-memory dedupe

const seen = new Map<string, number>();
const DEDUPE_WINDOW_MS = 5 * 60 * 1000; // 5 minutes

export async function alert(message: string) {
  const key = message.slice(0, 200); // use first 200 chars as dedupe key
  const last = seen.get(key);
  if (last && Date.now() - last < DEDUPE_WINDOW_MS) return; // skip
  seen.set(key, Date.now());

  // ... rest of the send logic
}

This means the same alert won't fire more than once every 5 minutes, but different alerts still go through. A retry loop firing the same exception 800 times in 10 minutes will produce 3 Telegram messages, not 800. You'll still know it's happening.

Redis-backed (for multi-instance apps)

If your app runs on multiple servers, in-memory dedupe doesn't work. Use Redis:

import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);

export async function alert(message: string) {
  const key = `tg-dedupe:${hash(message.slice(0, 200))}`;
  const set = await redis.set(key, '1', 'EX', 300, 'NX');
  if (set !== 'OK') return; // already alerted in last 5 min

  // ... send to Telegram
}

The EX 300 NX does the magic: set the key with a 5-minute TTL, but only if it doesn't already exist. If two servers try to send the same alert simultaneously, only one wins.

What to alert on (the harder question)

The tutorial above is the easy part. The hard part is what to alert on. Bad alerts → alert fatigue → muted bot → you miss the real ones.

Five things that are usually worth a Telegram ping:

Uncaught exceptions in the main process — these usually mean a process is about to die or has died.
Job queue depth above N — if Sidekiq/BullMQ/Celery has more than e.g. 1000 jobs queued, something is producing faster than consuming. Investigate.
5xx error rate above 1% — not every 500 needs a ping, but the rate exceeding a threshold does.
Specific business events that mean money is leaking — failed payment retries, stale webhook signatures, expired refresh tokens.
Cron jobs that didn't run — if your nightly backup didn't fire by 3:30am, you want to know at 3:30am, not at 9am when you check email.

Five things that are usually NOT worth a ping:

Individual 4xx errors (these are mostly user error or scrapers).
Slow queries (log them, don't page on them).
Anything you can't act on in the next 30 minutes.
Anything where the action is "do nothing, it'll resolve itself" (most CDN hiccups, most rate-limit blips).
Anything informational ("user X signed up" — use a different channel for celebration).

The test I use: if I'm at dinner and my phone buzzes, will I be glad I knew, or annoyed? If the answer is "annoyed," it doesn't belong on Telegram.

A note on alert resolution

A subtle thing most tutorials skip: alerts should also tell you when something is fixed. If your job queue depth crossed 1000 and you got pinged, you also want a "now back to 0" ping when it normalizes. Otherwise you spend 20 minutes manually checking the dashboard.

The simplest pattern:

let inAlertState = false;

export async function checkQueueDepth(depth: number) {
  if (depth > 1000 && !inAlertState) {
    await alert(`🔴 Queue depth: ${depth}`);
    inAlertState = true;
  }
  if (depth < 100 && inAlertState) {
    await alert(`🟢 Queue back to ${depth}`);
    inAlertState = false;
  }
}

Two messages per incident, not 200. Your bot stays usable.

When to stop building this and use a platform

Everything above takes about an evening to wire up properly. For a small team, that's a great trade.

There are three signs it's time to stop building this and use a platform that does it:

You're spending more than 1 day a quarter maintaining your alerting setup.
You realize you need pattern detection (retry loops, token spikes, anomalous response times) — those are much harder to write yourself than threshold alerts.
You've muted your own bot more than once.

That's the gap Belmo fills. The platform tails your production logs, runs pattern detection automatically (retry loops, token spikes, hot fingerprints, anomalous latency, silent cron failures), and pings you on Telegram with a link to the relevant logs. No code in your app, no Redis dedupe to maintain — it's part of the hosting layer. €19/mo Hobby, €35/mo Pro.

If you're already deployed somewhere else, the homemade Telegram setup above is a fine start — and probably better than no alerts at all.

What to do after you finish reading this

Concretely, in the next 30 minutes:

Create the bot via BotFather.
Get your chat ID with getUpdates.
Add TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID to your env vars on whatever platform you use.
Drop the alert(message) helper into your codebase.
Wire it to your top-level uncaught exception handler.
Add the dedupe logic so a runaway loop doesn't spam you.

That's the minimum viable production alerting setup for any app. It costs $0, works in any country, lives on your phone, and survives every channel rotation in your team.

If you wire something interesting on top of this — anomaly detection, business event alerts, anything cool — drop it in the comments. I'm always looking for new patterns to steal.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.

DEV Community: Chalom Ellezam

Stop sending every alert to Slack. The 4-channel routing matrix I built after 18 months of being paged at the wrong time.

Why piping everything into one channel stops working around month three

The four channels, evaluated by what they actually do at 03h

The matrix that picks the channel for you

A 30-line router that does all of this

The three routing mistakes that cost me real sleep

What I built around all of this

What to do tonight, regardless of which platform you ship on

What I still get wrong

Previous posts in this series

Your indie SaaS has no staging environment. Here is the 30-minute setup (and the 4 production bugs it catches before your users do).

Why most solo founders skip staging

The four bugs staging actually catches

The 30-minute setup

1. A separate branch (3 minutes)

2. A separate web service (5 minutes)

3. A separate database (8 minutes)

4. Separate secrets (7 minutes)

5. A separate URL (2 minutes)

What changes about your workflow

A note on CI

The trap nobody warns you about: stale staging

What I built

What to do tonight, regardless of platform

Closing question

Previous posts in this series

Your Postgres will die at 50 concurrent users, not 50,000. Here is the connection pooling guide nobody handed you.

Why Postgres has a seat limit at all

Why this bites indie SaaS specifically

The math you should actually do tonight

When you need PgBouncer, and when you just need to fix your app

The PgBouncer config that actually works

The prepared statement footgun

What about Supabase, Neon, and the managed providers

What I built

What to do tonight regardless of which platform you use

What I do not know

Previous posts in this series

Your .env file is probably already in your Git history. The 15-minute audit (and the 5 habits that stop new leaks for good).

Why secrets leak more in 2026 than they did in 2020

The 15-minute audit you can run tonight

Step 1: scan the full Git history, not just the working tree

Step 2: check GitHub's secret scanning UI

Step 3: rotate every key the audit found

Step 4: purge the secret from Git history (optional but worth it for public repos)

The 5 habits that stop the next leak

Habit 1: .gitignore is the first file in every new repo

Habit 2: a pre-commit hook that runs gitleaks

Habit 3: prod env vars live in the hosting platform, never in a file on disk

Habit 4: scope keys aggressively, and prefer short-lived ones

Habit 5: a monthly 5-minute rotation calendar event

What I built (the one Belmo mention)

What to do tonight regardless of which platform you use

An honest closing

Previous posts in this series

I deployed 12 vibe-coded apps to production. The same 6 things broke every single time.

Why vibe-coded apps fail in production specifically

Pattern 1: The API key that shipped in the JS bundle

Pattern 2: The unbounded query that nukes the database

Pattern 3: The CORS wildcard that opens the front door

Pattern 4: The timezone mismatch nobody notices until billing

Pattern 5: The file path that works on your laptop and nowhere else

Pattern 6: The background work that never runs

What I built, because I kept solving these manually

What to do tonight, regardless of which platform you use

The honest closing

Your crontab is silently failing. The 5 silent killers of VPS-based cron jobs (and the modern setup that fixes them in an afternoon).

Killer #1: you edited the wrong crontab

Killer #2: the environment your job runs in isn't your shell

Killer #3: output goes to /dev/null, errors go nowhere

Killer #4: your VPS is a single point of failure

Killer #5: overlapping runs corrupt your data

The modern setup, in three pieces

A real before/after

What about background workers vs cron?

What I built

What to do tonight regardless of which platform you use

Honest closing question

Your Stripe webhook is going to silently drop a paid customer. Here are the 4 patterns that catch it before they chargeback.

Habit 1: `.gitignore` is the first file in every new repo

Habit 2: a pre-commit hook that runs `gitleaks`

1. Your `.env` file is in your git history

10. You have no `/healthz` endpoint

Bite 1: The `heroku_ext` schema doesn't exist anywhere else

Bite 2: `pg_stat_statements` is enabled by default on Heroku, often not elsewhere

Bite 3: Heroku's `DATABASE_URL` bakes in `sslmode=require`

Bite 5: Heroku's `DYNO` env var doesn't exist anywhere else