Database Low Disk Alert Severity

A low-disk alert is not informational when the volume holds database files, WAL/binlogs, temp space, or backup staging. Severity should reflect remaining write runway, not just the metric name.

Runbook: Severity Is A Routing Contract

1. Do not key severity only by metric name. Low disk needs the current level: threshold breach, hard floor breach, and write runway.
2. Use both free percent and absolute GB. A 4% free value can be safe on a large archive volume but critical on a small log volume; 2 GB free can be critical even when percent looks acceptable.
3. Define at least two thresholds: WARNING for policy breach, CRITICAL for near-write-failure or less than one maintenance window of runway.
4. Do not suppress the first transition into CRITICAL, even if the low-disk gate only notifies on worsening breaches.
5. Route severity consistently: INFO to trend dashboards, WARNING to tickets/team channel, CRITICAL to paging or urgent incident queue.
6. Include owner context in the alert: data, logs/WAL/binlogs, temp, backups, snapshots, or monitor-generated logs.
7. Test with example volumes so downstream webhooks, Teams/Slack cards, and filters see the right severity.

I agree this should not fall through to INFO. For a database volume, low disk is a capacity and availability risk, and severity should reflect the current level rather than only the metric name.

Acceptance checks I would add:
- Volume Free Space below the configured threshold renders at least WARNING.
- A second hard floor, such as 2-3% or 1-2 GB free, renders CRITICAL.
- The alert includes both percent free and absolute GB free.
- The first transition into CRITICAL is emitted even if the low-disk gate suppresses repeated non-worsening breaches.
- Downstream webhook/card routing receives the same severity that the UI displays.
- Tests cover the current example: 4% free / 66 GB on a thresholded volume should not be INFO.

Do Not Treat As Info

• Database log, WAL, binlog, or temp volumes that can stop writes.
• Backup staging volumes where the next job can publish a partial or failed artifact.
• Monitoring-generated logs that can fill the same host they are supposed to protect.
• Any volume whose free space is below one maintenance window of write runway.