For an L1 or L2 support engineer, roughly how much of a typical workday is spent testing, troubleshooting, performing root-cause analysis, and identifying and documenting issues? Do these roles ever require engineers to examine application or software behavior in depth, or do they mainly focus on infrastructure and standard procedures?
I'm preparing to apply for L1 and L2 roles and freelance work. I'm currently building case studies that demonstrate how I investigate and document issues involving WordPress servers, Nginx, Apache, OpenLiteSpeed, and similar environments. Is creating this kind of troubleshooting and root-cause-analysis portfolio useful when applying for entry-level and intermediate support positions?
3 Answers
Your portfolio idea is worthwhile, especially if the case studies show your process instead of only showing that you fixed something. For each example, explain the symptoms, environment, impact, checks you performed, evidence from logs or monitoring, hypotheses you considered, the confirmed cause, the fix or workaround, and how you would prevent a recurrence. Include sanitized commands, diagrams, timelines, and clear documentation where appropriate. WordPress, Nginx, Apache, and OpenLiteSpeed examples can demonstrate useful skills, but try to show transferable methods such as HTTP troubleshooting, DNS, TLS, permissions, processes, resource usage, configuration management, and escalation. Be careful not to claim a definitive root cause unless your evidence supports it.
I would not expect an L1 engineer to perform deep root-cause analysis regularly, but basic troubleshooting and testing are definitely part of the job. L1 might verify service status, check recent changes, review straightforward logs, test connectivity, confirm permissions, follow a runbook, and document what happened. L2 usually goes further by tracing requests, reviewing application and web-server logs, checking configurations and dependencies, reproducing the issue, and determining whether the cause is infrastructure, software, or user-related. The exact boundary depends on the organization.
It varies a lot by the company, team structure, and the type of incident. L1 usually follows documented procedures, gathers information, performs basic checks and tests, confirms the problem, and escalates when the issue is outside the runbook. L2 generally handles more complex troubleshooting, compares logs and configurations, reproduces problems, applies fixes or workarounds, and may investigate patterns across multiple incidents. A typical L1 role may spend much of the day on ticket handling and standard troubleshooting, while L2 often spends a larger portion investigating unusual or recurring problems. Formal root-cause analysis is more commonly owned by senior engineers or L3, although L1 and L2 should still collect useful evidence and contribute to it.
That helps. So even when L1 or L2 does not own the final RCA, they still need to investigate far enough to provide good evidence before escalating?
The role descriptions online can make L1 sound like nothing more than ticket routing, but good L1 work involves asking precise questions, isolating symptoms, and escalating with complete notes rather than just passing the ticket along.