L1 vs L2 vs L3 at a glance
Level | Who | Typical tasks | Access | Escalates to |
|---|---|---|---|---|
L1 | Service desk, first-line support agents | Password resets, access requests, known issues from a runbook, logging and sorting tickets | Ticketing system, control panels, read-only monitoring | L2, when the fix isn't in the runbook or needs the command line |
L2 | Support engineers, system administrators | Diagnosing from logs and metrics, configuration fixes, most incidents | SSH or RDP, | L3, when the root cause is unclear or the fix needs a code or architecture change |
L3 | Senior engineers, architects, the developers of the product | Root cause analysis, architecture changes, bug fixes in code | Full admin rights, source code, infrastructure as code | L4, when the problem is in a vendor's product |
L1 Support
What is L1 and what can you expect from it?
This support is called first-line support. The main channel of interaction with the client for them is chat, telephone and e-mail. Most often, technical knowledge of L1 tech is limited compared to L2 or L3 tech. Usually, the L1 support team deals with requests that have a known answer or a written procedure (a runbook): password resets and access requests, checking an alert against the runbook, restarting a service when the instructions say so, or walking the client through a control panel or a cloud console (cPanel, DirectAdmin, Plesk, etc).
If you need to use the command line to solve a problem, have technical skills, and deeply understand the problem of the client, usually, they will escalate these cases to L2 L3 tech, depending on the type and complexity of the problem.
In many companies, L1 also answers pre-sale questions and the support chat.
L2 Support
What is L2 and what functions does it perform?
L2 techs have more technical skills and experience than L1 techs. They can perform most of your technical tasks. Since these tasks are more complex, L2 support engineers may need direct access to the server or the cluster (RDP, SSH, kubectl, etc) and dig into logs and metrics. They can also solve your technical issues and can fix most server problems without escalating them further.
Besides that, they can also prevent these problems from appearing in the future. If there are problems that L2 can’t solve and deeper investigation is needed, then they usually escalate the task to the L3 engineer. In our experience, most of the tasks are performed by L2 engineers, so this is our main resource.
L3 Support
What is L3 and what duties does this level have?
L3 engineers are the most senior specialists, with many years of technical experience. Depending on the company, these are senior system administrators, the developers of the product, or, in our case, the team lead of the project’s DevOps team. They can fix almost all the problems on the server side that require high skill and knowledge. In addition to this, they don’t only have support skills, but are also capable of finding the root cause, changing the architecture, and setting up the infrastructure from scratch.
Summing up, all high-level tasks that L1 L2 can’t cope with are escalated to the L3 engineer. And after a deep investigation of the problem, an L3 engineer is able to evaluate the task and execute it.
Some companies add two more levels to this model. L0 is self-service: a knowledge base, a status page, or a chatbot that lets users solve simple issues on their own. L4 is outside support from the software or hardware vendor, for example, a cloud provider’s support team, when the problem sits in their product.
When a ticket moves up a level
Escalation works when the rules are written down, not left to the person on shift. The usual triggers:
- No runbook. L1 has no written procedure for the problem, or the procedure didn't work.
- Access. The fix needs rights the current level doesn't have, like SSH to production or a change in the cloud account.
- Time. The ticket isn't solved within the time the SLA gives that level.
- Impact. Many users are affected, or the problem touches security or data, so it goes straight to an engineer.
Three numbers show whether the model works: first-contact resolution (the share of requests solved by the first person who takes them), escalation rate (how many tickets move up a level) and mean time to resolve. If almost everything gets escalated, L1 is a mail forwarder and the client waits twice.
What tiered support is for and who needs it
Tiered support exists so that the expensive, senior people don’t spend their day on password resets, and simple requests don’t wait in a queue behind a complex outage. Each request lands on the cheapest level that can actually solve it, and goes up only when it has to.
How the levels look depends on who you are:
- In-house IT (a company supporting its own employees) usually has all of them: a service desk as L1, system administrators as L2, and senior engineers or architects as L3, with vendors as L4.
- Product and SaaS companies put L1 on customer support, L2 on support engineers who can read logs and reproduce bugs, and L3 on the developers who own the code.
- Companies that outsource infrastructure to a DevOps or managed services partner often don’t need a separate L1 for the infrastructure. Their own team reports the problem, and the alerts go straight to engineers who can fix it.
If you are in the last group, the question to ask a partner isn’t “do you have L1, L2 and L3?” but “who gets the alert at 3 a.m., and can that person fix it?”
How it works at ITsyndicate
Every project has a dedicated team of engineers who work on it during the day. They know the infrastructure because they built or took over that exact setup, not because they read about it in a handover note.
Outside working hours, the same engineers are on an on-call rotation. Alerting is set up for each project, so when something breaks at night, the on-call engineer gets the alert, gets up, and fixes it.
In the terms of this article:
- L2 is the engineer on rotation. They handle the alert, diagnose it, and fix most incidents on their own.
- L3 is the team lead of the project. If the problem needs a deeper investigation or an architecture change, it goes to them.
We don’t have a separate L1 line for incidents: alerts go straight to an engineer who has access and knows the project. Account managers help with planning and non-technical questions during business hours on working days, and they are not part of the incident response. For a hosting company in Iceland, this looks like a 24/7 support chat where an engineer always answers.
If you want to know how this would look for your infrastructure, see our 24/7 infrastructure support services.