Write an on-call runbook for an alert

Write a runbook for the alert below, for an on-call engineer who may not know this service well and is reading it at night under pressure, so that they can judge the impact and act without waking the service owner unless they need to.

Alert definition (name, condition, threshold, where it fires):
"""
{{alert_definition}}
"""

What the service does and what depends on it: {{service_description}}

Notes from past incidents with this alert, chat threads, or the owner's know-how:
"""
{{past_notes}}
"""

Dashboards, log queries and commands available: {{tools}}
Escalation contacts and rules: {{escalation}}

Use these headings:
1. What this alert means: two sentences in plain words.
2. Impact check: how to tell within 5 minutes whether users are affected, with the exact dashboard or query.
3. Likely causes: a table with the columns Cause, How to confirm, Fix or mitigation, from the past notes, most common first.
4. Safe first actions: numbered steps that cannot make things worse, each with the exact command where one exists.
5. Risky actions: steps that need a second person or the owner's approval, and why.
6. Escalate when: specific conditions, with who to contact and how.
7. After the incident: what to record and where.

Keep it under 600 words. Put every command in a code block exactly as it should be typed, with values that change shown as placeholders in angle brackets, for example <pod-name>.

Use only commands, dashboards and causes that appear in the material above. Do not invent commands, flags, metric names or links, because a wrong command in a runbook gets run. Where a step clearly needs a command the material does not give, write "[command needed: what it should do]" so the owner can fill it in. If you cannot tell whether a step is safe, put it under Risky actions. If the notes disagree about a cause or a fix, include both and mark it for the owner to settle.