# Alerting

DanubeData alerts you when something needs attention — either against thresholds you set yourself, or automatically when a resource's health degrades. Alerts arrive by email and in the in-app Notification Center, and critical alerts can also be sent to a webhook.

## Metric alerts

Metric alerts let you set your own thresholds on a resource's core metrics — **CPU usage**, **memory usage**, and **disk usage** — and be notified when they're crossed.

### How they work

- **Threshold + comparison** — for example, *CPU usage greater than 90%*.
- **Duration** — the condition must hold for a sustained period before the alert fires (default 5 minutes for CPU and memory, 10 minutes for disk), so a brief spike won't notify you.
- **Breach and resolve** — you get an email when the threshold is breached, and another when the metric returns to normal.
- **Delivery** — email and the in-app Notification Center.

Sensible defaults are filled in for you (for example, a 90% CPU threshold), and you can adjust the threshold, comparison, and duration to fit your workload. Alerts are evaluated every minute.

### Creating a metric alert

1. Open the resource you want to monitor.
2. Go to its **Alerts** section and click **Create Alert**.
3. Choose the metric, threshold, comparison, and duration.
4. Save — the alert is evaluated from then on, and you can edit or delete it, or review a history of when it fired and resolved.

Each resource can have up to 10 alerts, and each team up to 50.

### Examples

| Metric | Condition | Duration |
|--------|-----------|----------|
| CPU Usage | greater than 90% | 5 minutes |
| Memory Usage | greater than 90% | 5 minutes |
| Disk Usage | greater than 85% | 10 minutes |

## Pod health alerts

Separately from the thresholds you set, DanubeData watches the health of your running resources around the clock and alerts you automatically the moment one runs into trouble — no configuration required.

- **Covered resources** — Databases, Cache, Queues, Managed Apps, VPS, and Serverless Containers.
- **What it catches** — problems like crash loops, out-of-memory, and image-pull failures.
- **Notified immediately** — the moment an alert opens, your whole team is notified by email and in the Notification Center, with the reason included. If you have a webhook configured, the alert flows through it too.
- **On the page** — a warning banner appears directly on the affected Database, Cache, Queue, or Managed App page.
- **Self-clearing** — the alert clears itself automatically once the resource recovers.

Serverless Containers additionally get deploy-failure alerts: if a new revision fails to roll out while your last healthy version keeps serving, your team is emailed and a `serverless.build_failed` webhook fires (when webhooks are enabled). See the [Rapids docs](https://docs.danubedata.ro/serverless-overview) for details.

## Notification channels

- **Email** — includes the resource, the metric or issue, the value and threshold, and a link to investigate.
- **In-app Notification Center** — every alert also appears in the dashboard.
- **Webhook** — critical alerts (such as pod health issues) are POSTed to your configured webhook endpoint with signed payloads.

Choose which categories reach you from **Profile → Notification Preferences**.

### Webhook payload

Webhook deliveries share a common envelope:

```json
{
  "event": "pod.health.issue",
  "timestamp": "2026-07-14T10:30:00+00:00",
  "category": "pod_health_issue",
  "severity": "critical",
  "data": {
    "title": "Container health issue",
    "message": "prod-postgres restarted repeatedly (CrashLoopBackOff)",
    "resource_type": "database",
    "resource_id": 123,
    "resource_name": "prod-postgres",
    "team_id": 1,
    "team_name": "Acme",
    "action_url": "https://danubedata.ro/databases",
    "action_text": "View Details"
  }
}
```

Point the webhook at any HTTPS endpoint you control — your own service, or a tool that accepts inbound webhooks.

## Best practices

1. **Start conservative** to avoid alert fatigue, then tune thresholds against your baselines.
2. **Use the duration** so short, self-correcting spikes don't fire an alert.
3. **Know your normal** — check the [Metrics](https://docs.danubedata.ro/monitoring-metrics) page to understand typical ranges before setting thresholds.

## Troubleshooting

**Not receiving alerts?**
- Check the recipient email address (and your spam folder).
- Confirm the category is enabled in **Profile → Notification Preferences**.
- For webhooks, confirm the endpoint is reachable and returns a 2xx response.

**Too many alerts?**
- Raise the threshold, or lengthen the required duration.
- Remove alert rules you no longer need.

## Related Documentation

- [Monitoring Overview](https://docs.danubedata.ro/monitoring-overview)
- [Metrics](https://docs.danubedata.ro/monitoring-metrics)
- [Logs](https://docs.danubedata.ro/monitoring-logs)
- [Uptime Checks](https://docs.danubedata.ro/monitoring-uptime)