LEARN. PRACTICE. GROW.Concept and mechanism
L2 support turns an initial report into a situation defined well enough to act on or escalate. Its boundary with L1 and L3 depends on the organization: establish service scope, applicable runbook, authorized access, and change decision ownership. Start with expected and observed behavior, affected users, known onset, and last confirmed success. An alert measures a condition; it does not establish business impact by itself. Link related symptoms without losing original identifiers and avoid competing interventions against the same failure. Priority should reflect impact and urgency under agreed criteria, including batch deadlines and dependencies that can amplify failure.
Guided application
In a fictional scenario, a reporting portal becomes slow while a funds process stops producing a file required for closing. Establish whether a workaround exists, how much work is pending, and the consumer deadline. Record facts separately from hypotheses, assign an owner, and set the next update. If the procedure allows diagnostic collection but requires approval for restart, prepare that decision with evidence and risk. Do not wait for a definitive cause before communicating confirmed impact or requesting help. This discipline supports operational autonomy while keeping actions within the authority granted to the role.
A CPU alert and a missing file require different questions about impact.
Common pitfalls
Priority by arrival order; assuming authority from a job title; waiting for root cause before communicating.
Related topics: Useful hypotheses and evidence · Diagnosis by layer · Operational mitigation and validation
Establish impact, scope, and authority before choosing an intervention.
Reference: Incident response · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30