Incident Severity Levels for Web Agencies: P1–P4 Template

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

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.

---

Originally published at pingvera.com.