BugsRadar

Production, staging, dev: one chat or several

Updated 1 October 2026 · BugsRadar team

The same code runs in production, on staging and on three laptops. The errors from all of them should not land in the same place with the same weight, and a staging error should never read like a production one at 2 a.m.

Set the environment where the app starts

Each package takes the environment as a setting: Environment in the .NET configuration (the host's environment name fits), the environment option in Node.js (NODE_ENV fits), environment= in Python's init, and ?environment= for a script on the HTTP endpoint. From then on every message carries it: Production · web-1 · v1.4.2.

Counted apart

The same error in two environments is counted separately, so Staging and Production never share a message: a bug you are reproducing on staging doesn't inflate the production count, and a production error doesn't hide behind a staging one. See What you receive.

One chat: the Free setup

With one channel, everything arrives in one chat and the environment is the second line of every message. For a solo developer or a small team that is usually enough: you read "Staging" and move on.

Several chats: rules

On the Pro plan a channel can take only the errors that fit its filter. Give staging a channel that nobody has notifications on, give production the team's group and a Pushover for Critical, and let a channel without a filter catch everything else. An error that fits no channel goes nowhere, and the project's page warns you when every channel has a filter. See Rules.

Development machines

Errors from laptops are rarely worth a message. The simplest way to keep them out is not to register BugsRadar in the development configuration at all; the second simplest is a filter that no development environment fits. Either way, keep the key out of the repository: see Keep the API key secret.

One project or one per environment?

One project per application, with the environments inside it, keeps the count of projects small and the rules simple. A project per environment works too and needs no rules, at the cost of two projects per app; on Pro that cost is nothing, since projects are unlimited.

Where to go next

Rules is the routing. The first hour after a deploy is staging-first in practice.

Next: .NET Framework apps still in production →