Outcome
By the end of this lesson, you will be able to assign the right severity for any finding, control noise without changing severity, and route each severity level to the appropriate response channel.
| Prerequisites | M2.1.L1 · T1.M1.6 (notifications) |
| Time | 9 minutes |
1. Concept
Five levels, and each one carries an implied answer to “by when”.
Without them a list of 400 findings is 400 equally urgent things, which means none of them is urgent. With them, the list sorts itself.
LEVEL MEANING TIMELINE─────────────────────────────────────────────────────────────critical Security risk or major waste Todayhigh Significant cost or compliance gap This weekmedium Worth addressing This sprintlow Nice to have Backloginfo Informational only No action requiredThe timeline isn’t aspirational; it’s the operational contract. Critical findings get same-day attention; info findings live in dashboards for context.
Built-in recommendations use only the first four levels. Info appears only on findings from custom policies you author.
How severity is assigned
Each rule has a default severity in its definition. What happens next depends on the family:
1. COST FINDINGS (idle, rightsizing, orphan, discount, schedule) Scored 0-100, then bucketed: 90+ critical 70-89 high 40-69 medium < 40 low Inputs: savings compared with an org-relative reference (2.5% of your trailing 7-day daily spend, plus $10/day), so the same dollar figure scores higher in a small org than a large one confidence low weight; orders findings within a band waste_ratio low weight; rightsizing, discount and schedule only
2. EVERYTHING ELSE (compliance, reliability, security, governance, performance, advisory) Keeps the severity the rule declares. Example: RDS publicly accessible: critical RDS not Multi-AZ: high Storage without a CMK: mediumThere are no fixed dollar bands, and the two families do not compound: a posture finding’s severity comes from its rule, not from a dollar figure.
Severity is not tuned per rule
One built-in severity policy applies to every org, so the same finding gets the same label everywhere. There is no settings page to downgrade or upgrade a rule. You change what reaches people, not the label:
QUIET a noisy rule Scenario: 200 low-severity findings per day clutter the review Action: filter or sort the Recommendations list by severity; dismiss specific findings for 1 week to 6 months, or Forever for ones you have accepted Effect: the label is unchanged; your team's view gets shorter Use when: a rule fires correctly but is not worth acting on now
RAISE attention for your org's risk model Scenario: regulated industry; Multi-AZ is required by policy Action: a recommendation policy (Governance > Policies) that matches RC-005 (RDS not Multi-AZ) and notifies a channel or opens a Jira ticket Effect: every new RDS without Multi-AZ reaches the owning team Use when: a rule matters more to you than its label suggestsWrite down why each policy or long dismissal exists, so the next reviewer can judge it.
Routing severity to action
A recommendation policy can match on severity (critical, high, medium, low) and then notify channels or open a ticket for each newly surfaced finding. Most teams build a contract like this (general notification routing is covered in T1.M1.6.L4):
SEVERITY ROUTING RESPONSE TIME────────────────────────────────────────────────────────────────────────critical On-call via webhook Same day + #finops-alerts Hours, not days + email to platform lead
high #finops-alerts This week + per-team channel Days + weekly digest
medium Per-team channel This sprint + weekly digest email Weeks
low Weekly digest only Backlog + visible in dashboard Best effort
info No policy; dashboard only No SLA + visible in dashboard Reference onlyThe routing is the contract between detection and action. Without it, alerts become noise.
Severity hygiene anti-patterns
ANTI-PATTERN FIX──────────────────────────────────────────────────────────────────Everything routed as critical Scope policies by severity; page only on critical
Severity ignored Add severity to the policyin routing conditions
Policies and long dismissals Record why each one existswithout doc Audit annually
Severity doesn't match impact Trust the dollar-based default Add a rule-scoped policy if a rule matters more to you
Static routing (never reviewed) Quarterly review Add policies as the estate grows Retire policies and dismissals that no longer earn their placeThe hygiene is the quarterly review. Without it, severity drifts.
Severity vs urgency vs importance
SEVERITY = ZopNight's classification of the findingURGENCY = how fast must we act (varies by team / context)IMPORTANCE = does this matter (largely captured by severity)
EXAMPLE: critical-severity finding for a known issue ZopNight: critical Team's urgency: low (already planned for next sprint) Importance: high (real issue; just not new)
ROUTING: still notifies because the SLA says soTEAM RESPONSE: acknowledges; works on planned scheduleThe severity is the standardized classification; urgency is the team’s interpretation. Both matter.
How severities accumulate over time
A typical org’s severity distribution:
SEVERITY DISTRIBUTION (mid-size estate, steady state):
critical: < 5 open at any timehigh: 20-50 openmedium: 100-300 openlow: 500-1000 open
OPEN AGE (average):critical: < 1 dayhigh: 3-7 daysmedium: 14-30 dayslow: evergreenThis is the “healthy” pattern. Deviation signals process problems:
- 30+ open criticals: routing broken or team overwhelmed
- 100+ open highs: SLA being missed
- 500+ open mediums: prioritization unclear
- Very low totals: rules underconfigured or estate is tiny
Reading severity distribution
The distribution itself is diagnostic:
WHAT THE DISTRIBUTION TELLS YOU:
CRITICAL count growing: Routing or response process broken Or: new issue class emerging Investigate immediately
HIGH stuck at >50: Team can't keep up with the load Consider dismissing accepted findings OR more people for action
MEDIUM age increasing: Backlog growing Quarterly cleanup needed
LOW not growing: Likely suppressed/disabled rules Audit: are valuable signals being missed?The distribution monitoring catches process drift early.
2. Demo
A team’s severity audit (mid-size, mature ops):
QUARTERLY SEVERITY AUDIT (Q1 2026):
CURRENT DISTRIBUTION: SEVERITY OPEN COUNT TYPICAL AGE TREND vs LAST QUARTER critical 3 < 1 day flat (healthy) high 47 3-7 days flat medium 184 14-30 days up 8% (manage) low 623 evergreen flat
HEALTH ASSESSMENT: 3 critical = healthy (low; resolved fast) 47 high = manageable (within SLA) 184 medium = growing slightly (watch; plan extra cleanup) 623 low = bulk; appropriate
ACTION FROM AUDIT: - Quarterly cleanup sprint for medium-severity Target: down to 150 by end of Q2 - Policies and dismissals reviewed: - RDS Multi-AZ policy kept (notifies #platform; org accepts the SLA) - 3 Forever dismissals re-checked (still accepted risk) - Routing reviewed: - Critical → PagerDuty: confirmed working (last incident T+12 min) - High → #finops-alerts: confirmed; team's avg response 3 days
CONTROL CHECK: Last critical: incident 2026-02-15 Notification fired: T+0 Acknowledged: T+8 min (PagerDuty) Resolved: T+34 min SLA metThe audit confirms severity + routing is working. Quarterly cadence keeps it healthy.
3. Hands-on (4 min)
Run severity audit on your estate:
□ STEP 1: Open Recommendations; group by severity critical: _____ high: _____ medium: _____ low: _____
□ STEP 2: Check open ages Critical's oldest: _____ days (target: <1) High's oldest: _____ days (target: <7) Medium's oldest: _____ days (target: <30)
□ STEP 3: For each critical Action this week? □ Yes □ No Owner: __________
□ STEP 4: Check routing Critical routes to: __________ High routes to: __________ Confirm: notifications actually firing
□ STEP 5: Quarterly review reminder Date: __________ Owner: __________A 10-minute audit reveals the health. Quarterly cadence maintains it.
4. Knowledge check
Q1
An RDS instance is public-internet accessible. Likely severity:
A. low
B. critical
C. medium risk
D. high
Show answer
Correct: B. Critical. Posture findings keep the severity their rule declares, and the RDS public-access rule declares critical. No dollar figure is involved.
Q2
A team’s channel gets 800 low-severity notifications per day. The fix:
A. Hire more engineers
B. Disable the offending rules entirely across the whole org now
C. Add a severity condition so the policy only sends high and up
D. Downgrade the noisy rules to info in severity settings
Show answer
Correct: C. Severity is the lever for routing, not something you edit. Scope the notify policy to critical and high; the low findings stay in the Recommendations list. There is no per-rule severity setting, and disabling rules loses signal entirely.
Q3
An idle EKS cluster would save $5,000/mo. What decides its severity?
A. The saving compared with the org’s own daily spend
B. A fixed dollar band shared by every organization
C. Whether the cluster carries a production tag
D. How many days the finding has been open
Show answer
Correct: A. Cost findings are scored against an org-relative reference (2.5% of trailing 7-day daily spend plus $10/day). $5,000/mo lands critical for an org spending under about $6K a day, and lower for a much larger one.
5. Apply
Severity labels are fixed by ZopNight. Use Governance > Policies to route findings by severity (notify a channel or open a Jira ticket), and dismissals to quiet findings you have accepted.
For your team: quarterly severity + routing audit. Confirm SLAs being met; adjust policies to your org’s risk model.
Related lessons
- L1: The 11 categories
- L3: Rule interface (next)
- L4: Pricing model
- L5: Reading a recommendation card
- T1.M1.6.L4: Severity routing