Incident Response Threshold

Overview

The Incident Response Threshold feature enables administrators to define standard response time targets for incidents across the organization.

This feature allows you to configure:

• MTTA (Mean Time to Acknowledge)
• MTTR (Mean Time to Resolve)
• Retrigger Time
• Threshold values per incident priority (P1–P5)

Some competitors refer to this feature as an “Incident Timer” or “Incident Timing” mechanism.

Important: Incident Response Threshold is not an SLA calculator or SLA tracker. It only monitors and alerts on time-based breaches.

Incident Response Thresholds define the time limits for responding to and resolving incidents based on their priority. These thresholds help ensure timely action and automatic escalation when response expectations are not met.

Each incident priority can have its own MTTA, MTTR, and Retrigger configuration.

Threshold Parameters

If Any Parameter is set as 0, then that parameter will not be applied while processing Incident.

Example: If MTTA is 0 then we won't apply MTTA check.

1. MTTA (Mean Time to Acknowledge)

• The maximum allowed time to acknowledge an incident after it is created.
• If the incident is not acknowledged within this duration, it is considered MTTA breached.

Example:

If MTTA is set to 5 minutes, the incident must be acknowledged within 5 minutes of creation.

2. MTTR (Mean Time to Resolve)

• The maximum allowed time to resolve an incident after it is created.
• If the incident remains unresolved beyond this duration, it is considered MTTR breached.

Example:

If MTTR is set to 2 hours, the incident must be resolved within 2 hours of creation.

3. Retrigger

• The time limit to re-trigger an incident after it breached MTTR
• Applies when an incident remains unresolved after MTTR breach.
• Retrigger must use a time greater than 5 minutes or 0

Example:

If Retrigger is set to 5 minutes, and there is a valid MTTR, then after MTTR breach the incident will be re-triggered after 5 minutes if not resolved with in that time.

Priority-Based Configuration

Response thresholds are configured per incident priority, allowing stricter limits for critical incidents and more relaxed limits for lower-impact issues.

P1 - Very short MTTA - Very short MTTR - Frequent Retrigger

P2 - Short MTTA - Short MTTR - Regular Retrigger

P3 - Moderate MTTA - Moderate MTTR - Moderate Retrigger

P4 - Long MTTA - Long MTTR - Infrequent Retrigger

P5 - Optional MTTA - Optional MTTR - Optional Retrigger

*Actual values are fully configurable based on operational requirements.

Escalation Behavior

• When MTTA or MTTR is breached, the incident enters a response threshold-breached state.
• The system automatically triggers High urgency notification rules and start the escalation
• Escalations continue based on the breached interval until:
• The incident is acknowledged (for MTTA breaches), or
• The incident is resolved (for MTTR breaches).
• The Escalation completed

Manage Incident Response Threshold

Incident Response Threshold is available at 3 levels.

1. Global
2. Under a Team
3. Under a Service

1. Global Level

Global Incident Response Thresholds have a global scope. If a team does not have its own settings, these global settings will be applied to incidents under that team.

Where to find:

Go to Incident Response Threshold under the Workspace category in the Callgoose SQIBS Dashboard

If Incident Response Threshold is enabled at the Global level, the same configuration will be visible at both the Team and Service levels.

In these sections, the setting will appear with the label “Inherited from Global.”

When you see the “Inherited from Global” indication under the Incident Response Threshold tab at the Team or Service level, it means that the configuration is currently controlled by the Global settings.

If the Global Admin has permitted overrides, teams or services can modify these values to define their own Incident Response Threshold settings according to their operational requirements.

2. Team Level

Team-level Incident Response Thresholds have a team-level scope. If a service does not have its own settings, these team settings will be applied to incidents under that service.

Where to find:

Go to Incident Response Threshold under the specific Team's info section in the Callgoose SQIBS Dashboard

3. Service Level

Service-level Incident Response Thresholds have a service-level scope. These settings will be applied to incidents under this service.

Where to find:

Go to Incident Response Threshold under the specific Services's info section in the Callgoose SQIBS Dashboard

Best Practices

• Keep MTTA and MTTR aggressive for high-priority incidents.
• Use Retrigger to avoid missed escalations, but not so frequently that it causes alert fatigue.
• Align thresholds with SLA commitments.
• Review and adjust thresholds periodically based on response performance.

Difference Between Incident Response Threshold and SLA Tracker

Do not confuse Incident Response Threshold with the SLA Tracker. These are two different mechanisms.

Incident Response Threshold

• Works as an incident timer
• Monitors acknowledgment and resolution times
• Triggers alerts when:
• MTTA is breached
• MTTR is breached
• Does not calculate SLA percentage
• Does not generate SLA compliance reports

This feature strictly tracks response timing thresholds.

SLA Tracker and Its Relationship to Incident Response Threshold

You can configure SLA Tracker via:

Workspace → SLA Tracker

When setting up an SLA Tracker, you will see the following option:

"Do you want the incident threshold to override the services in the selected projects?"

If enabled:

• The Incident Response Threshold values for services linked to the selected projects will be overridden
• SLA-specific MTTA and MTTR values will apply
• It is highly recommended to enable this when SLA commitments are contractually defined

Key Point – SLA Tracker Processing Logic

The SLA Tracker engine evaluates SLA computations automatically whenever an incident is created, based on the configuration defined in your SLA Tracker settings.

Within the SLA Tracker configuration, you define specific SLA threshold values for alerting purposes. Each time an incident is generated:

• The SLA engine recalculates the applicable SLA metrics.
• It evaluates the remaining allowable downtime.
• It compares the remaining downtime against the configured SLA alert thresholds.
• If the remaining downtime reaches or breaches the defined alert threshold level, notifications are triggered according to the configured SLA Tracker escalation policy.

This process ensures proactive alerting before an SLA violation fully occurs, enabling teams to take corrective action within the committed service levels.

Important Clarification

The SLA Tracker is a comprehensive SLA management framework. It is designed to:

• Calculate SLA compliance
• Monitor accumulated downtime
• Apply SLA threshold alerting logic
• Trigger escalation policies
• Support contractual SLA commitments

Summary: Incident Response Threshold vs SLA Tracker

The Incident Response Threshold feature and the SLA Tracker feature are two completely separate mechanisms.

• They operate independently.
• They serve different operational and compliance purposes.
• They are not dependent on each other.
• Each can be configured and used independently.

You may enable and configure both features based on your business requirements, without one affecting the core functionality of the other (unless explicitly configured within SLA Tracker settings to override Incident thresholds when you set up SLA Tracker).

Clarification on SLA Tracker and Incident Response Threshold Override

During SLA Tracker configuration, there is an option to allow the SLA Tracker to override the Incident Response Threshold values ("Do you want the incident threshold to override the services in the selected projects?").

This process works as follows:

• If no Incident Response Threshold values have been previously configured,
• And the override option is enabled during SLA Tracker setup,

The SLA Tracker engine will automatically calculate optimal Incident Response Threshold values based on the defined SLA percentage and populate them into the Incident Response Threshold settings.

Important Notes

• This is a one-time population task performed at the time of SLA Tracker setup.
• The system does not continuously sync or dynamically link these values.
• After the initial population, administrators can modify the Incident Response Threshold values at any time.
• Changing Incident Response Threshold values later does not impact the core SLA computation logic.

Key Understanding

Although SLA Tracker can populate Incident Response Threshold values during setup (if enabled), both features remain architecturally independent.

• SLA Tracker is responsible for SLA compliance calculation and downtime tracking.
• Incident Response Threshold is responsible for response-time-based alerting.
• There is no continuous dependency between the two mechanisms.

Each feature can be configured, modified, and used independently according to your operational and contractual requirements.

Explore the resources below to learn more about SLA tracker

SLA Tracker KB

SLA Tracker Product page

FAQs

Q1. What is the difference between "Incident Response Threshold" and SLA Tracker?

Incident Response Threshold

• Similar to “Incident Timer” or “Incident Timing” used by some competitors
• Monitors acknowledgment and resolution timing
• Sends alerts when threshold breaches occur
• Does not calculate SLA percentage
• Does not generate SLA compliance metrics

SLA Tracker

• Supports multiple SLA models
• Calculates SLA compliance percentage
• Includes MTTA and MTTR tracking within its SLA engine
• Suitable for contractual SLA commitments
• Provides comprehensive SLA monitoring and reporting

In short:

• Incident Response Threshold = Operational timing alert
• SLA Tracker = Full SLA compliance engine

Q2. If I want to check Product SLA performance, what should I use?

You must use the SLA Tracker.

Only SLA Tracker can:

• Track SLA compliance
• Calculate SLA percentages
• Generate SLA-based reporting
• Align with contractual commitments

Incident Response Threshold alone cannot provide SLA performance metrics.

Q3. Where can I configure Incident Response Threshold?

Incident Response Threshold can be configured at three levels:

• Global level (workspace-wide default)
• Team level
• Service level

Administrators can define MTTA, MTTR, and retrigger values depending on the governance model used in the organization.

Q4. What does “Inherited from Global” mean in the threshold settings?

When the Global administrator enables Incident Response Threshold and defines threshold values, the same configuration is automatically applied to Teams and Services.

In these cases, the settings screen will display “Inherited from Global”, indicating that the configuration is controlled by the Global level.

Q5. Can Teams override Global threshold values?

Yes, but only if the Global administrator allows overrides.

If override permission is granted, Teams or Services can modify MTTA, MTTR, and Retrigger Time according to their operational requirements.

Q6. What happens if a Team does not configure its own thresholds?

If a Team does not define custom thresholds, the system will automatically use the inherited Global configuration.

This ensures consistent response timing policies across the workspace.

Q7. What happens if thresholds are configured at both Team and Service levels?

Service-level thresholds take priority over Team-level settings.

The hierarchy works as follows: Service Level → Team Level → Global Level

The most specific configuration always applies to the incident.

Q8. How does the system detect an MTTA breach?

An MTTA breach occurs when the time taken for the first acknowledgment exceeds the configured MTTA threshold for the incident priority.

When this threshold is exceeded, the system triggers the configured alert or escalation notification.

Q9. How does the system detect an MTTR breach?

An MTTR breach occurs when the incident remains unresolved beyond the configured MTTR threshold.

If the incident is not resolved within this time window, breach notifications are triggered.

Q10. Where can I view MTTA and MTTR breach reports?

MTTA and MTTR breaches can be viewed in the Incident Reports section.

Navigate to:

Incident Reports → Apply Filters → MTTA Breach / MTTR Breach / SLA Breach

This allows teams to analyze response performance and incident handling efficiency.

Q11. What happens after a threshold breach occurs?

When a threshold breach occurs:

• The system generates a breach alert
• Escalation policies may be triggered
• Retrigger notifications may continue until the incident is acknowledged or resolved
• This ensures that delayed responses are actively surfaced to responsible teams.

Q12. Does Incident Response Threshold work with escalation policies?

Yes.

Incident Response Threshold integrates with escalation policies, enabling organizations to automatically escalate incidents when response or resolution times exceed defined thresholds.

Q13. Can threshold alerts be retriggered multiple times?

Yes.

The Retrigger Time configuration determines how often breach alerts are repeated if the incident remains unresolved.

This prevents missed alerts and ensures continuous visibility of delayed incidents.

Q14. What happens if Incident Response Threshold is disabled?

If the feature is disabled:

• MTTA and MTTR breach monitoring stops
• No threshold-based alerts will be triggered
• Incident handling continues normally without response-time enforcement

Q15. Does Incident Response Threshold affect incident severity or priority?

No.

Incident priority is determined during incident creation.

Incident Response Threshold only monitors whether response and resolution times exceed the configured limits for that priority.

Q16. Can different services use different threshold policies?

Yes.

Each service can define its own MTTA, MTTR, and Retrigger Time values, allowing organizations to tailor response expectations based on the criticality of the service.

Q17. What happens when an incident priority changes?

If the incident priority changes, the system will apply the threshold values associated with the new priority level.

This ensures that the correct MTTA and MTTR targets are enforced based on the updated severity.

Q18. Does Incident Response Threshold calculate SLA percentage?

No. It only monitors MTTA, MTTR, and retrigger timings. It does not compute SLA compliance metrics.

Q19. What happens if Global Admin enables Incident Response Threshold?

Global-level settings will override team-level configurations across the workspace.

Q20. Can teams define their own thresholds?

Yes, if Global Admin has not enforced organization-wide thresholds.

Q21. Does this feature support different thresholds for different priorities?

Yes. You can configure separate MTTA and MTTR values for P1 through P5 incidents.

Q22. What is Retrigger Time?

Retrigger time defines how often breach alerts are re-notified if the incident remains unresolved beyond the threshold.

Q23. If SLA Tracker is enabled, will it automatically modify Incident Response Threshold values?

During SLA setup, administrators may choose to allow SLA Tracker to populate optimal threshold values. This is a one-time configuration task. After that, thresholds can be modified independently at any time.

Q24. Does changing Incident Response Threshold affect SLA compliance calculations?

No. SLA calculations operate within the SLA Tracker engine and are not dependent on Incident Response Threshold settings.