# Configure alerts

Notify your Team about application and database symptoms, then inspect, test, or silence an alert.

Canonical: https://docs.deliberate.space/operate/alerts/

Attach alerts to the Component or database whose behavior matters. Alert policy
travels with the resource and Environment instead of relying on a separate
monitoring configuration.

## Add application alerts

Declare alerts on a Component:

```yaml
resource: component
name: app
image: registry.deliberate.cloud/acme/app:1.4.2
cpu: 1
memory: 2Gi
alerts:
  - name: repeated-restarts
    type: restart_count
    threshold: 3
    window: 10m
  - name: elevated-errors
    type: http_error_rate
    threshold: 5
    window: 10m
    minRequests: 100
    recipients:
      - on-call@example.com
```

Apply the Project to create or update the policy. If `recipients` is omitted or
empty, the Team owner is notified. Recipient addresses are deduplicated within
one alert, but separate alerts produce separate notifications.

## Choose an alert type

| Type | Target | Threshold means | Additional field |
| --- | --- | --- | --- |
| `log_pattern` | Component or database | Matching log lines | `pattern` is required and case-sensitive |
| `restart_count` | Component | Container restarts | — |
| `memory_pressure` | Component | Memory used as a percentage of its limit | — |
| `cpu_throttle` | Component | Throttled CPU periods as a percentage | — |
| `http_error_rate` | Component | 5xx responses as a percentage | `minRequests` is required |
| `http_latency` | Component | Request latency in milliseconds | `percentile`: `p50`, `p95`, or `p99` |
| `db_backup_age` | Database | Hours since the last successful backup | Point-in-time check; no rolling window |
| `db_connection_saturation` | Database | Connections as a percentage of the limit | — |
| `db_disk_usage` | Database | Storage used as a percentage | — |

Rolling windows accept durations from `1m` through `24h`. Start with symptoms a
user would notice or an operator can act on. Avoid alerting on high CPU
utilization alone: `cpu_throttle` tells you when the configured ceiling is
actually slowing the Component.

## Configure a deployed Blueprint

A Blueprint may ship default alerts. Select its node on the Environment canvas
to inspect them. Choose **Customize alert policy** to replace the defaults for a
Component in that Blueprint instance; you can revert to the maintainer's policy
later. The same sheet also contains its CPU, memory, and replica limits.

## Inspect and test alerts

```sh
deliberate alerts list --env production
deliberate alerts events app elevated-errors --env production
deliberate alerts test app elevated-errors --env production
```

Component alerts are the default. Add `--kind databases` when addressing a
database alert. Testing exercises the notification path without waiting for the
real threshold to be crossed.

## Silence an alert temporarily

Use a bounded silence during maintenance or while actively handling an incident:

```sh
deliberate alerts silence app elevated-errors \
  --env production \
  --for 2h \
  --reason "planned migration"
```

The alert policy remains intact and resumes automatically when the silence
expires. Remove it early with:

```sh
deliberate alerts unsilence app elevated-errors --env production
```

A silence suppresses notifications; it does not fix the underlying condition.
Review event history and the Component or database health before closing the
incident.

## Next steps

- [Troubleshoot an unhealthy deployment](/operate/observe-and-recover/)
- [Adjust application resource configuration](/build/configuration/)
- [Review Team access to operational controls](/teams/access/)