For L1 and L2 engineering roles, roughly how much of a normal workday is spent testing, troubleshooting, performing root-cause analysis, and identifying and documenting issues? Do these engineers typically investigate software deeply when necessary, or do they mainly stay focused on the infrastructure layer?
I'm preparing to apply for L1/L2 jobs and freelance work, and I'm building case studies that demonstrate how I diagnose, analyze, and document issues involving WordPress servers, Nginx, Apache, OpenLiteSpeed, and forum platforms. Would projects like these be useful additions to my portfolio, and what should I emphasize?
4 Answers
There isn’t a standard percentage. It depends heavily on the company, team, ticket volume, and how responsibilities are divided. Some days may involve almost no investigation, while an incident-heavy day can be dedicated almost entirely to troubleshooting and follow-up documentation. Job descriptions often label a surprisingly broad range of technologies as “infrastructure,” especially from a management perspective.
L1 and L2 engineers absolutely may need to investigate software, not just servers and networking. The depth varies: L1 might follow known procedures and gather logs, while L2 is more likely to trace requests, inspect configurations, reproduce failures, analyze application behavior, and work with developers. In unusual cases, engineers may even need to reverse-engineer or decompile software to identify the cause.
Your portfolio idea is worthwhile. Make each case study look like a real incident report: describe the symptoms, environment, investigation steps, evidence from logs and monitoring, hypotheses you tested, the confirmed root cause, the fix, and how you verified it. Include commands or configuration examples where appropriate, but remove secrets and personal information. Showing a structured process matters more than simply listing technologies.
Automation and AI-assisted log analysis are already reducing some repetitive L1/L2 investigation work. Tools can help correlate events and suggest likely causes, but engineers still need to validate the result, understand the systems involved, and explain the impact clearly. Learning how to use these tools alongside Linux, web servers, networking, databases, and basic application debugging would make your portfolio more relevant.
A practical investigation usually starts by clarifying the reported symptoms and timeline, checking whether the issue is reproducible, and comparing the affected system with a healthy one. From there, engineers review monitoring data, logs, recent changes, DNS and network behavior, service status, resource usage, and application configuration. They narrow the possibilities, test one change at a time, document the evidence, and confirm that the fix resolved the original problem.