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.

Managed Kubernetes clusters

A cluster's alerts live on the cluster, not on its worker nodes, and are set from the cluster's Alerts tab. The available metrics are the worker nodes' CPU usage, memory usage, disk usage, CPU steal and load ratio, and the threshold is compared against the busiest node — so CPU usage greater than 90% fires when any one node crosses 90%, which is the node you would want to know about. A cluster with no worker registered yet is not evaluated until one joins.

The cluster's Observability tab shows the same node metrics over time, alongside what the platform saw once a minute: how many nodes and pods the cluster reported, whether the control plane answered, and each add-on's health history. That history is kept for 30 days.

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