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

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 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:

{
  "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 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
• Metrics
• Logs
• Uptime Checks