How Many Errors Can Telebugs Process on a Small VPS?

I recently added a small load testing tool to Telebugs because I wanted to answer a simple question without hand-waving:

How much can Telebugs actually handle on a cheap VPS?

I had rough estimates on the homepage for a while. They were conservative, but they were still estimates. That bothered me. If I am going to say Telebugs runs well on modest hardware, I should be able to show where the number came from.

So I built bin/load, a repeatable benchmark harness that starts a throwaway Telebugs instance, creates a real project token, sends real Sentry envelope requests with k6, waits for the ingest queue to drain, and prints both intake and processing numbers.

The First Number Was Tempting

My first serious run was on my MacBook Pro. It looked good at first: Telebugs accepted more than 130 errors per second with no failed ingest requests.

That is the kind of number you want to put on a marketing page immediately. But it would have been the wrong number.

The benchmark also showed a queue backlog. Telebugs was accepting reports faster than the background processor could fully process them. That is not a failure. That is exactly why the ingest queue exists. But it means the honest capacity number is not "how many HTTP requests did the app accept during the k6 run?"

The honest number is:

How many reports were fully processed end-to-end, including the time needed to drain the queue?

That distinction matters. A queue can absorb bursts. It cannot make a tiny server process infinite traffic forever.

The CX23 Test

To get a fairer baseline, I ran the benchmark on a Hetzner CX23 VPS:

• 2 vCPU
• 4 GB RAM
• 40 GB local disk
• Telebugs running in Docker

I ran three 10-minute tests:

bin/load --users 100 --duration 10m --read-ratio 0 --groups 200 --drain-timeout 3600
bin/load --users 100 --duration 10m --read-ratio 10 --groups 200 --drain-timeout 3600
bin/load --users 100 --duration 10m --read-ratio 20 --groups 200 --drain-timeout 3600

The read-ratio controls how much of the load is browsing the authenticated UI instead of sending errors. A ratio of 0 is pure ingest. A ratio of 20 means roughly 20% of iterations load Telebugs UI pages while the rest send errors.

The Results

The ingest-only test accepted 100,846 errors in 10 minutes at 167.73 errors per second. That is a useful burst intake number, but the queue peaked at 72,498 pending payloads and took another 20 minutes to drain. End-to-end, the server processed 55.84 reports per second.

The mixed tests are more interesting to me. With UI reads happening at the same time, Telebugs settled around 50 processed reports per second end-to-end. The 20% read test finished with a tiny queue and processed 50.08 reports per second overall.

That is the number I feel comfortable publishing.

The Number on the Homepage

After these runs, I updated the hardware table to say that a 2 vCPU / 4 GB RAM server can process about 50 reports per second, or about 4.3 million reports per day.

I also updated the docs to explain the difference between:

• Envelope accept rate, which is burst intake.
• Reports processed end-to-end, which is sustained processing.

This is less flashy than saying "Telebugs does 167 errors per second on a tiny VPS." It is also much more useful.

If your application has a bad deploy and sends a spike of errors, Telebugs can accept the burst and chew through the queue afterward. If your normal steady-state traffic is above 50 errors per second on this class of server, you should use more hardware.

That is the whole point of measuring it this way. I do not want the sizing table to be impressive for five seconds and misleading for the person who actually has to run the thing.

Why I Like This Result

I like small systems. Telebugs runs in one container, uses SQLite, and keeps the background jobs in the same box. There are fewer moving parts to install, monitor, update, and explain when something goes wrong.

That is easy to say when the traffic is tiny. The interesting question is whether the simple setup still holds up when you push it.

This test made me feel good about that choice. A small VPS processing around 50 complete error reports per second is plenty for many teams, and it still leaves room for the occasional bad deploy that sends a burst of errors all at once.

That is what I want Telebugs to be: boring to run, clear when something breaks, and fast enough that you do not have to think about the infrastructure first.

Reproducing the Benchmark

If you have the Telebugs source code, you can run the same benchmark with bin/load. It starts a throwaway performance instance, so it does not benchmark or pollute your production installation.

For capacity planning, look at these lines in the final summary:

• Reports processed end-to-end
• Drain time
• Peak pending ingest payloads
• HTTP p95 latency
• Failed jobs

The full methodology is now in the system requirements section of the manual.

Telebugs is a self-hosted Sentry alternative that runs on your own server, with no event quotas and no monthly surprise. Learn more at telebugs.com.