Skip to content

Severity & Response Framework#

This section defines how Stakater classifies incidents and how communication and follow-up are handled after initial response.

The framework applies uniformly across all Stakater products and services.

1. Severity Classification#

Severity is determined based on business impact.

Severity Definition
P1 – Critical Production outage or severe business impact. No viable workaround exists.
P2 – High Major degradation of production functionality. A workaround may exist but is not sustainable.
P3 – Medium Limited or non-critical functionality affected. A reasonable workaround exists.
P4 – Low Information requests, configuration guidance, minor issues, or enhancement questions. No production impact.

Severity influences response time targets and escalation handling.

If no severity is selected when submitting a request, it defaults to P3 – Medium.

Stakater reserves the right to adjust severity based on actual business impact.

2. Initial Response#

Initial response refers to acknowledgement and engagement by a Stakater engineer.

During initial response, the assigned engineer will:

  • Validate severity and impact
  • Begin investigation
  • Request additional information if required
  • Outline immediate next steps

Response time targets are defined in the Support Plans & SLA section.

3. Ongoing Communication#

Support does not end at first response. Communication continues until the issue is resolved or formally closed.

Communication frequency depends on severity:

P1 – Critical#

  • Active investigation begins immediately.
  • Regular updates provided until service stability is restored.
  • Escalation initiated automatically under Premium.

P2 – High#

  • Progress updates provided during investigation.
  • Escalation as required based on impact and complexity.

P3 – Medium#

  • Updates provided as investigation progresses.
  • Follow-up communication aligned with business-hours coverage.

P4 – Low#

  • Response and follow-up provided within standard SLA timelines.

Communication is handled via the Support Portal unless otherwise agreed.

4. Escalation Model#

Escalation is triggered by:

  • Business impact
  • Lack of progress
  • Customer request (if justified)

Under Premium support, P1 incidents are automatically escalated to senior engineering.

Management visibility is introduced when required based on severity and operational impact.

5. Resolution#

An incident is considered resolved when:

  • Service functionality is restored, or
  • A verified workaround is implemented, or
  • The customer confirms closure

Resolution may involve:

  • Configuration changes
  • Bug fixes
  • Vendor coordination
  • Upgrade recommendations

Resolution time is not guaranteed and depends on technical complexity and external dependencies.

6. Post-Incident Review#

For high-severity incidents, Stakater may conduct a structured review.

This may include:

  • Root cause analysis
  • Timeline reconstruction
  • Preventative recommendations
  • Operational improvement suggestions

Under Premium support, post-incident reviews may be formally included as part of service engagement.

7. Continuous Improvement#

Stakater uses incident data and trends to improve platform stability and operational processes.

Feedback during and after case resolution is welcomed and may be incorporated into product and service improvements.