Monitoring error rates without the hosted bill

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. A popular hosted error tracker’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. The bigger enterprise observability platforms 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, compatible with the common error-tracking SDKs)

GlitchTip is an open-source error tracker that implements the same ingest protocol used by the most widely adopted hosted error trackers. That matters: you use the standard client SDK your language ecosystem already ships for that class of tool, point it at your own GlitchTip server, and everything just works. If you ever want to switch to a hosted error tracker later, you change one URL.

Run it with Docker Compose on a small VPS. A €5/month 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 client SDK for your error tracker and point the DSN at your server:

import * as ErrorTracker from "your-error-tracking-sdk";

ErrorTracker.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-host the full stack of a hosted error tracker (only if you have the RAM)

Some hosted error trackers are open source themselves, 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 that platform’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 a specific hosted tracker’s ecosystem and have spare compute: self-host its full stack.

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 common error-tracking SDKs?

Yes. GlitchTip implements the same ingest API used by the most widely adopted hosted error trackers, so their official client 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 a hosted tracker 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. GlitchTip’s JavaScript SDK support 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.