Skip to main content
Stackbastion

Draft, not yet published

Monitoring error rates for a solo-founder app without an enterprise budget

7 July 2026· 5 min read · by Stackbastion

Your app is live. Users are signing up. And you have no idea if it’s throwing 500 errors right now, because the only way you find out is when someone emails you. The enterprise monitoring tools all start at prices that make sense for a team of 20, not for you.

You need to know when things break. You don’t need to spend €100 a month to find out.

Why this happens

Error monitoring got expensive because the big vendors price per event. Every error, every performance trace, every user session counts against a quota. Sentry’s team plan starts around $26/month but the useful features (longer retention, more events, performance monitoring) push most real apps into the $80 to $100 range fast. Datadog and New Relic are worse, built for companies that treat observability as a line item.

For a solo founder with a few hundred users, that pricing is upside down. You might throw 500 errors in a busy week. Paying enterprise rates to track 500 events is like renting a warehouse to store one box.

The good news: the actual technology behind error tracking is not complicated. It’s a service that catches exceptions, groups them by fingerprint, and alerts you. Several open-source and cheap options do exactly that.

How to fix it

You have three realistic paths, cheapest first.

Option 1: log-based alerting (free, crude, good enough to start)

If your app already writes structured logs, you can alert on error patterns without any new service. Say your Node app logs JSON to stdout and Docker captures it. A tiny script can tail the logs and ping you when errors spike.

Here’s a minimal approach using journalctl and a cron job that counts errors in the last 5 minutes and sends a Telegram message if the count crosses a threshold:

#!/usr/bin/env bash
# /usr/local/bin/error-alert.sh
set -euo pipefail

THRESHOLD=5
BOT_TOKEN="your-telegram-bot-token"
CHAT_ID="your-chat-id"

count=$(journalctl -u myapp --since "5 minutes ago" \
  | grep -c '"level":"error"' || true)

if [ "$count" -ge "$THRESHOLD" ]; then
  curl -s "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
    -d chat_id="${CHAT_ID}" \
    -d text="Alert: ${count} errors in the last 5 minutes on myapp"
fi

Run it every 5 minutes with cron:

*/5 * * * * /usr/local/bin/error-alert.sh

This won’t group errors or show you stack traces in a nice UI. But it tells you when something’s on fire, which is 80% of the value, for free.

Option 2: GlitchTip (self-hosted, Sentry-compatible)

GlitchTip is an open-source error tracker that speaks the Sentry protocol. That matters: you use the official Sentry SDK in your app, point it at your own GlitchTip server, and everything just works. If you ever want to switch to hosted Sentry later, you change one URL.

Run it with Docker Compose on a small VPS. A €5/month Hetzner box handles a solo app easily:

# docker-compose.yml
services:
  glitchtip-web:
    image: glitchtip/glitchtip:latest
    depends_on:
      - postgres
      - redis
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://glitchtip:changeme@postgres:5432/glitchtip
      SECRET_KEY: generate-a-long-random-string-here
      REDIS_URL: redis://redis:6379/0
      GLITCHTIP_DOMAIN: https://errors.yourdomain.com

  glitchtip-worker:
    image: glitchtip/glitchtip:latest
    command: celery -A glitchtip worker -l info
    depends_on:
      - postgres
      - redis
    environment:
      DATABASE_URL: postgres://glitchtip:changeme@postgres:5432/glitchtip
      SECRET_KEY: generate-a-long-random-string-here
      REDIS_URL: redis://redis:6379/0

  postgres:
    image: postgres:17
    environment:
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: glitchtip
    volumes:
      - glitchtip-pg:/var/lib/postgresql/data

  redis:
    image: redis:7

volumes:
  glitchtip-pg:

Then in your app, use the standard Sentry SDK and point the DSN at your server:

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://[email protected]/1",
  tracesSampleRate: 0.1,
});

You get grouped errors, stack traces, release tracking, and email alerts. Total cost: one small VPS you probably already have.

Option 3: self-hosted Sentry (only if you have the RAM)

Sentry itself is open source, and you can run the full stack. Be honest about the cost: the official self-hosted setup wants at least 4GB of RAM and pulls in Kafka, ClickHouse, and a dozen containers. It’s a real operational burden for one person. Unless you specifically need Sentry’s advanced features, GlitchTip gives you 90% of the value at 10% of the maintenance.

Which to pick

  • A few hundred users, tight budget: start with log-based alerting, it’s free and takes an hour.
  • You want a real UI and grouped errors: GlitchTip on a €5 VPS.
  • You’re already deep in the Sentry ecosystem and have spare compute: self-hosted Sentry.

Whichever you choose, set up the alert first. An error tracker you never look at is the same as no tracker. Wire it to Telegram, Slack, or email so the errors come to you.

Or, we do it for you

Setting up monitoring, alerting, and the VPS to run it on is exactly the kind of ops work that eats a founder’s weekend. Our free audit checks whether your app has any error visibility at all, and if it doesn’t, we set it up as part of managed hosting. You get told when things break, before your users tell you.

FAQ

Is GlitchTip really compatible with the Sentry SDK?

Yes. GlitchTip implements the Sentry ingest API, so the official Sentry SDKs for JavaScript, Python, and most other languages send data to it without changes. You only swap the DSN URL. That also means no vendor lock-in: moving to hosted Sentry later is a one-line change.

How many errors is too many to self-host?

For a solo app doing thousands of events a day, a €5 to €10 VPS handles GlitchTip fine. Once you’re into millions of events a month, the storage and processing start to matter and hosted plans become worth comparing again. Most solo founders never hit that.

Do I even need error monitoring if I have logs?

Logs tell you what happened after you go looking. Error monitoring tells you what’s happening now, groups repeated errors so you don’t drown, and alerts you without you checking. Start with log-based alerts if budget is zero, but a real tracker saves you hours once you have any traffic.

What about frontend errors?

The same tools cover the browser. The Sentry (and GlitchTip) JavaScript SDK catches unhandled exceptions in the browser and sends them to the same server. That’s how you find out a button is broken for real users on a browser you never tested.

Related posts