Incident Severity Levels for Web Agencies: P1–P4 Template

August 8, 2026 · 6 min read

Incident severity should describe current business impact, not how difficult the fix appears or how upset the loudest stakeholder is. A small web agency can use four levels: P1 for critical business interruption or serious data/security risk, P2 for major degradation, P3 for limited non-critical failure, and P4 for low-impact defects or planned improvement.

Classify using the affected journey, scope, duration, workaround, timing, data integrity, and contractual obligations. Reassess severity whenever those facts change.

At a glance

Level	Practical meaning	Typical agency response
P1 Critical	Critical journey unavailable, broad impact, no safe workaround, or serious security/data risk	Page immediately, declare incident, assign lead, notify client
P2 Major	Important function materially degraded or unavailable, but impact is contained or workaround exists	Urgent owner, structured updates, escalate if worsening
P3 Moderate	Limited function affected; main business journey remains available	Work through help desk within support target
P4 Low	Cosmetic, informational, minor performance, or improvement request	Prioritise in normal backlog

Severity is not the same as ticket order. A P3 regulatory deadline tomorrow may be scheduled before an old P2 with a stable workaround. Preserve both severity and operational priority.

The seven classification questions

1. Which business journey is affected? Checkout, lead capture, booking, login, publishing, or a secondary feature?
2. How many users, sites, or regions are affected? One editor, one client, or a shared platform?
3. Is there a safe workaround? Can customers use another payment method or contact channel?
4. Is data at risk? Loss, duplication, corruption, exposure, or incorrect financial state?
5. Is impact active? A present failure, a near-term expiry risk, or a historical defect?
6. Does timing amplify impact? Campaign launch, sale period, event, or out-of-hours audience?
7. What does the agreement require? Support hours, reporting deadlines, and notification triggers?

P1: critical incident

Typical conditions:

• revenue-critical website or checkout unavailable for a material audience;
• paid traffic points to a broken conversion path with no workaround;
• orders, payments, or customer records may be lost, duplicated, corrupted, or exposed;
• payment or contact details appear to be maliciously changed;
• a shared dependency affects several high-criticality clients;
• domain, DNS, or certificate failure makes the service broadly unusable;
• security compromise is suspected with active impact.

P1 means “activate the incident process now.” It does not promise a particular cause or repair time.

P2: major incident

Typical conditions:

• an important function is unavailable for some users or regions;
• checkout works only with a documented workaround;
• transactional email or CRM delivery is delayed beyond business tolerance;
• serious performance degradation causes abandonment;
• an integration backlog is growing but data can be reconciled;
• TLS/domain expiry is close enough to require urgent intervention.

A P2 can become P1 if scope grows, the workaround fails, or data risk appears.

P3: moderate incident

Typical conditions:

• one non-critical page or feature is broken;
• an editor cannot perform a routine task;
• a scheduled job is late but remains within recovery tolerance;
• isolated layout, content, analytics, or browser compatibility failure;
• a preventable risk has enough time for normal remediation.

P3 still needs an owner and due date. “Not urgent” must not mean “forgotten.”

P4: low impact or improvement

Typical conditions:

• cosmetic defects;
• content corrections without active harm;
• minor performance opportunities;
• feature suggestions;
• monitoring improvements discovered during review;
• technical debt with no current service degradation.

If it requires investigation, it can still be P4. Complexity does not define severity.

Copyable severity matrix

# Incident severity policy

## P1 — Critical
Trigger: Critical user journey unavailable, material active data/security risk, or broad impact without safe workaround.
Response: Immediate incident declaration and paging.
Client update: On confirmation; cadence [value].
Authority: [role] may perform documented emergency mitigation.

## P2 — Major
Trigger: Important function materially degraded; limited scope or safe workaround exists.
Response: Urgent owner within [target].
Client update: Within [target]; cadence [value].
Escalation: Promote to P1 if [conditions].

## P3 — Moderate
Trigger: Limited non-critical failure with primary journeys available.
Response: Help-desk target [value].
Client update: Normal support channel.

## P4 — Low
Trigger: Cosmetic issue, minor risk, or improvement request.
Response: Backlog/planning process.

## Reclassification
Any responder may request reclassification with evidence.
Severity is reviewed when impact, scope, workaround, or data risk changes.
All changes are timestamped with reason and approver.

Example classifications

Event	Initial level	Why	Possible change
Homepage down, checkout reachable through product links	P2	Major degradation, partial path remains	P1 if navigation blocks most buyers
Contact form says success but emails never arrive during paid campaign	P1/P2	Active revenue loss, invisible failure	Depends on alternate lead destination
One product image missing	P3	Limited impact	P2 if it is the only image for flagship launch
TLS expires in 45 days	P3	Time to act	P2 at urgent threshold; P1 if expired
Unknown admin plus injected payment script	P1 security	Integrity and customer risk	Remains P1 until contained and assessed
Editorial typo	P4	Cosmetic	P1/P2 if it creates material legal or safety misinformation

Context can change the same technical symptom. The matrix supports judgment; it does not remove it.

Response time is not resolution time

• Detection time: failure starts to signal received.
• Acknowledgement time: signal received to owned.
• Response time: request or incident confirmed to active work.
• Mitigation time: impact reduced or safe workaround available.
• Resolution time: agreed service restored.
• Recovery validation time: full journey and downstream state confirmed.

Do not promise a fixed resolution time for every P1 unless the agency controls all relevant dependencies and can meet the commitment. A response target is easier to control than a resolution target.

Common mistakes

• making every angry-client ticket P1;
• using technical difficulty as severity;
• keeping the original level after impact grows;
• defining P1 as “site down” and missing payment or lead-delivery failures;
• calling every security finding P1 without assessing active risk;
• having no authority attached to severity;
• mapping P1 directly to a guaranteed resolution time.

FAQ

Is P1 the same as Sev-1?

Often, but naming varies. Define one internal model and map client/vendor terminology explicitly.

Who may change severity?

Any responder should be able to present evidence; the incident lead or designated service owner should record the decision.

Should every site use the same matrix?

Use one meaning for P1–P4 across the agency, but define project criticality and business journeys per client.

Does a near-expiry domain count as an incident?

Usually it begins as a risk task. It becomes an incident when the remaining time and ownership uncertainty threaten continuity.

Sources and further reading

• Google SRE: Managing Incidents
• NIST SP 800-61 Rev. 3

Reviewed: 8 August 2026.

Next: Client website outage communication templates and website maintenance SLA template. Severity decides how loudly you respond; what you learn afterwards is a separate discipline — the blameless postmortem template covers it.

Pingvera can provide evidence for classification—failed journey, location, timing, domain/TLS risk, or form-delivery failure. The agency remains responsible for business severity.

Read next: Website Incident Report Template for Agencies · Website Maintenance SLA Template for Agencies · Post-Deployment Website Checklist for Agencies · Website Outage Incident Response Playbook · Run a free site check.