Rate, queue, payload, and disk guardrails keep one bad deploy from consuming the server that is supposed to help you fix it.
Four things: how fast reports arrive, how many are waiting, how much space those waiting payloads occupy, and how much disk remains. Oversized payloads get their own limits too. One runaway app does not get the whole server to itself.
During a real storm, yes, some excess reports may be rejected. Telebugs returns a standard 429 response before it stores the report or queues more work. Protecting the server is more useful than faithfully recording errors until the disk is full.
No. Admins see a banner explaining why intake is limited, with a shortcut to the right settings. The Ingest Protection page shows what Telebugs accepted and what each guardrail held back.
No. Telebugs ships with defaults based on its small-server benchmarks. If your hardware has more room, or you prefer a tighter ceiling, change the rate, queue, and disk thresholds from the UI.
