Alerts Practical By Samson Tanimawo, PhD Published Nov 6, 2025 4 min read

Alert Verb vs Noun Patterns

How alerts name themselves. Verbs vs nouns.

The pattern

Alert names should describe what is happening (verbs), not what is being measured (nouns).

"checkout-api-down" is better than "checkout-api-availability". "disk-filling-fast" is better than "disk-utilization".

Verbs tell the on-call what to do; nouns tell the on-call what to check. Action over observation.

Subject-verb structure. "checkout-latency-high", "queue-depth-growing", "replication-lag-breaking-rpo".

No abbreviations except for well-known terms (RPO, SLO, p99). "db-conn-exh" is not faster to read than "db-connection-pool-exhausted".

Lowercase, kebab-case, max 5 words. The name appears in 30 places (PagerDuty, Slack, JIRA, postmortems); brevity matters.

Searchable. Engineers searching for "high checkout latency" find the right alert when names use verbs.

Self-documenting. A new on-call reading "replication-lag-breaking-rpo" learns what the team cares about without opening a runbook.

Reduces ambiguity in postmortems. "Alert: queue-depth-growing" is clearer than "alert on queue depth".

Alert names like "alert1", "my-cool-alert", or "REVIEW THIS". They survive for years.

Names containing the threshold value. "cpu-above-80" rots when the threshold changes; use "cpu-above-threshold".

Names that include the team. "platform-team-disk-alert" couples the alert to org structure that changes more often than the alert itself.

Audit your alert catalog. Rename anything that describes a metric instead of a problem.

Add a naming convention to your alerting style guide. Block PRs that don't follow it.

Rename in batches; preserve old aliases for 30 days so dashboards keep working.