Sensible defaults,overridable at two levels.
You should not have to configure anything to get value. When you do want to tune something, here is exactly where it takes effect.
Start with nothing to configure
Every service type Beaam watches arrives with default rules already chosen. Connect a provider and it alerts sensibly the same minute — there is no threshold-setting step between connecting and being monitored, and for most people there never needs to be one.
The curation is deliberate. A tool with a hundred configurable rules is a tool that makes you responsible for its judgement, and the judgement is the product.
What a rule is
Six things, and the fifth is the one that keeps Beaam quiet.
| Part | Example | What it does |
|---|---|---|
| Metric | error rate | The signal being watched. |
| Comparison | at or above | Which direction is bad. |
| Threshold | 5% | The line. This is the number you usually want to change. |
| Severity | degraded, or broken | Whether this is worth interrupting you for. |
| Evidence | 2 of the last 3 | How many readings must be bad before it counts. |
| Enabled | on, or off by default | Whether the rule fires at all. |
Evidence is why one bad reading never pages you. Most rules require 2 of the last 3 readings to be over the line; slower or noisier signals use 3 of the last 5. A single failed check that recovers on the next poll is a blip, and waking you for it is how monitoring tools teach people to ignore them. How Beaam decides covers what happens after a rule does trip.
Three levels
Thresholds resolve from the bottom up, and the more specific level wins.
| Level | Scope | Where you set it |
|---|---|---|
| Beaam's defaults | Everything of that service type, for everyone | In Beaam. Nothing to do. |
| Your integration settings | Every service of that type in your account | The integration page — "all my MongoDB clusters" |
| A single service | That one resource | The service's own page — "except this cluster" |
The merge is per rule and per field, which is more useful than it sounds. Raise the threshold on one cluster and it keeps inheriting whether that rule is enabled; switch a rule off across the whole integration and any cluster that set its own threshold keeps that number for the day you switch the rule back on.
Resetting follows the same shape: clearing a service's override returns it to what it inherits — your integration setting if you have one, Beaam's default if you do not. A reset never jumps past your own configuration.
Why most metrics never alert
Beaam collects far more than it alerts on, on purpose. A metric with no rule is charted on the service page and stays quiet forever — useful the moment you are already looking at an incident, and never a reason to interrupt you. Every alertable metric is listed on its integration page, so what can and cannot page you is visible rather than inferred.
Some rules ship switched off. "Alert when this stops" is the usual case: a clean stop is normally something you did deliberately, so the rule exists, appears in the list with its threshold, and waits for you to turn it on.
And a rate carries the volume it needs. One failed request out of one is a 100% error rate and not an outage, so a rate rule declares its own denominator and does not evaluate below it. Where a service can genuinely fail outright at low volume — a small site returning errors to every visitor it had — that is a separate rule, so being small does not mean being unwatched.
Everywhere at once
Thresholds are part of the capability layer like everything else, so the same three levels are readable and settable from the API, the CLI and anassistant over MCP — not only from the web app. A threshold changed by an assistant is the same change, resolved the same way.
Questions
I changed a threshold on one cluster. Does it affect the others?
No. A change made on a service's own page applies to that service only. To change every service of one type at once, set it on the integration page instead — that is the level above.
What does resetting a cluster's threshold go back to?
The value it inherits, which is your integration-level setting if you have one and Beaam's default otherwise. It does not jump past your own configuration back to the code default.
Beaam collects a metric but never alerts on it. Is that a bug?
No, it is the design. Most collected metrics are charted for context and have no rule, so they inform you when you are already looking without ever paging you. Some have a rule that ships switched off — 'alert when this stops' is the usual shape, because a clean stop is normally something you did on purpose.
Why didn't a 100% error rate alert?
A rate needs a denominator to mean anything: one failed request out of one is a 100% error rate and not an outage. Rate rules declare the volume they need before they will evaluate, so a quiet endpoint does not page you for its only bad minute. Where a service can fail outright at low volume, there is a separate rule for that case.