Warnings, breadcrumbs and signals that look alike
How warning events, console.warn, breadcrumbs, SDK diagnostics, connection problems and a monitor's “Needs review” differ, and which ones alert.
Several things in Belvador are amber or say "warning", and they mean different things. This page lists each one, where it comes from, and whether it can send an alert.
| Signal | Where it comes from | Where you see it | Can alert? |
|---|---|---|---|
| Warning event | Your code: captureMessage("…", "warning"), or an event with level: "warning" | An issue with level Warning | Yes, if a rule's minimum level is Warning |
console.warn | Your code or a library writing to the console | Only as a breadcrumb on the next error, and only with instrument: { console: true } | No |
| Breadcrumb | Automatic (opt-in) or addBreadcrumb | The steps before an error, inside the issue | No |
| SDK diagnostic | The SDK noticing a setup mistake (BLV_… codes) | The browser or server console with debug: true; counted on the project's Connection tab | Through connection problems only |
| Connection problem (amber) | Belvador noticing that part of the app is not covered | The Connection tab | Yes — rule SDK connection problems |
| Monitor — Needs review | A job reported unknown: it ended but its effect is not known | Monitors | Yes — rule Monitor problems |
Warning events#
Use a warning event for something unusual that a person should look at, but that did not break the request: a fallback path taken, a retry budget almost used up, data in a shape you did not expect.
captureMessage("Price list fell back to cached copy", "warning");Warnings group into issues like errors. The default rule sends errors or higher, so warnings do not page anyone unless you create a rule with minimum level Warning — see Alerts.
Do not turn every console.warn into a warning event. Libraries warn about deprecations and dev-only behavior; those belong in your build output, not in your issue list.
SDK diagnostics are not app errors#
A diagnostic such as BLV_HOOK_MISSING or BLV_MONITOR_INVALID_SLUG means Belvador is set up wrong, not that your app is failing. Diagnostics never become issues. They are rate limited, visible in the console with debug: true, and the important ones surface as connection problems — see Verify the connection.
"Needs review" is not "failed"#
A monitor turns amber when a run ended with Outcome unknown: for example a payment was sent, the provider timed out, and the job cannot tell whether it went through. Nobody should retry blindly. Check the provider, then press Mark as reviewed on the incident. A run that clearly failed should report an error instead, which turns the monitor red.
Spotted something wrong or missing? Tell us: hello@belvador.dev