The seven things the platform watches, how to mute one resource without muting the kind, and what a cost estimate is not.
Alerts, costs and notifications
What the platform watches
Seven kinds, all per project, all with a built-in default an admin can override from the project's Manage panel on Projects. Raised incidents are listed on Alerts.
| Kind | Fires when |
|---|---|
| Pipeline failure spike | Too many runs failed within a window |
| Job failure spike | Too many background jobs of one kind failed within a window |
| Resource flapping | A resource's status changed state too often within a window |
| Disk usage high | An RDS instance or OpenSearch domain crossed a percent-used level |
| Connector sync failure | A connection's status sync threw |
| Service unhealthy | A service is running below the capacity it was asked to run |
| Alert email | Not a kind — the opt-in delivery setting alongside them |
Three of them are level checks rather than window counts, so the "window" field is ignored and the threshold means something different: disk usage reads it as a percent, service health as the minimum percent of desired capacity that must be running (default 100), and connector sync failure ignores it entirely. The settings panel says which is which rather than showing a field that does nothing.
Service unhealthy, and why it exists
An ECS service reports ACTIVE while every one of its tasks is crash-looping. Status-based checks
structurally cannot see that — there is no state transition to count and no unhealthy keyword to
match — so the only signal is running capacity against desired capacity.
Three readings deliberately do not raise:
A rollout in progress. Running below desired is what a deploy looks like. Alerting there means alerting on every deploy, which is how a kind gets muted and stops protecting anything.
A service scaled to zero on purpose. Not an outage.
A reading we could not take. It neither raises nor resolves — a momentary gap in the provider's answer clearing an open incident would report an outage as over while it is still happening.
Muting one resource
A service legitimately expected to look bad — a worker scaled to zero out of hours, something deliberately running degraded — is muted on its own Catalog tab, per alert kind. Not a single on/off: a resource can be a legitimate exception for one reason and not another, and one running at partial capacity on purpose should still alert when its status starts flapping.
Muting a kind resolves any open incident of that kind for that resource, because nothing else ever would — the check that resolves an incident is the one being switched off. Disabling a kind for the whole project deliberately does not, since that changes what gets detected from now on and silently closing every open incident would erase work somebody is in the middle of.
Notifications
The bell shows job completions, the Production approval lifecycle, alerts, and organization changes.
Every notification type is muted by default and opted into, per operator, from the bell's own settings. If you expected something and never got it, that is the first place to look.
Alert email is separate and per project: an admin enables it and supplies the recipients. A send failure never blocks or reverses the in-app notification.
Cost estimates
The cost figures on Resources, the Dashboard and Projects are list-price sizing estimates, computed from each resource's own configuration priced against the provider's public catalog. They are not your bill.
Specifically excluded, and this is why the number will not match an invoice:
Reserved Instance and Savings Plan discounts
Data transfer
Usage-volume charges — requests, load balancer capacity units, data processing
Some resource types are deliberately not priced rather than merely unfinished: Lambda's cost is invocation volume with no fixed floor, a resource group is not billable in its own right, and some providers publish no usable rate card. Those show a muted dash, never a zero — "we could not price this" and "this is free" are different statements.