Make response expectations clear.
Set acknowledgment and resolution time limits for each priority. Your most critical incidents can have the shortest windows.
INCIDENT RESPONSE THRESHOLD
Every incident has a clock. Make every minute count.
Know when an incident is taking too long to acknowledge or resolve. Set response limits by priority, detect breaches automatically, and alert the right engineers through your escalation policies—without waiting for someone to notice.
Priority-based timing Automatic escalation No SLA setup required
Response Threshold · Live exampleINTERACTIVE DEMO
Choose incident priority
ACKNOWLEDGE BY5 minMTTA threshold
RESOLVE BY45 minMTTR threshold
RETRIGGER10 minAfter MTTR breach
Incident createdMTTAMTTR
MTTA threshold breached
Still unacknowledged after 5 min. High-urgency notifications and escalation rules apply.
Illustrative values only. This preview does not trigger real alerts.
P1–P5 priority controls
MTTA & MTTR timers
Threshold breach alerts
Retrigger for unresolved incidents
WHEN SECONDS MATTER
Don't just start a timer. Set a response standard.
There is a big difference between knowing how long an incident has been open and making sure someone acts before the delay gets worse.
Escalate when time runs out.
When an active incident breaches a configured limit, SQIBS can trigger high-urgency notifications through its escalation workflow.
Keep human response in the loop.
Follow configured on-call and escalation policies so the incident is brought to the attention of the responsible engineers.
HOW IT WORKS
From incident created to action taken.
Once your response thresholds are configured, SQIBS watches the incident timeline and evaluates whether it has crossed the limits for its priority.
01
Set the response policy
Configure MTTA, MTTR and optional retrigger intervals for priority levels P1 through P5.
02
An incident starts the clock
SQIBS applies the relevant Global, Team or Service threshold when the incident is created.
03
Breaches raise the urgency
Late acknowledgment or resolution triggers the configured high-urgency notification and escalation behavior.
04
Keep unresolved work visible
Optional retriggering re-notifies after an MTTR breach, following the configured interval while the incident remains unresolved.
THREE SIMPLE CONTROLS
The right clock for every stage of response.
Choose exactly what to enforce. All three settings are configurable per incident priority and can be disabled individually with a value of zero.
MTTA Threshold
How long an incident may remain unacknowledged after creation. If it crosses the allowed time, SQIBS identifies the acknowledgment breach.
Example: P1 must be acknowledged within 5 minutes.
MTTR Threshold
The maximum time from incident creation to resolution. If the incident is still unresolved when the limit passes, SQIBS flags a resolution breach.
Example: P1 must be resolved within 45 minutes.
Retrigger Interval
After an MTTR breach, optionally re-trigger an unresolved incident at a configured interval to keep it visible to responders.
Example: Re-trigger every 10 minutes after MTTR breach.
Configuration detail: A value of 0 disables that particular check. A nonzero retrigger interval must be greater than 5 minutes. The examples here are illustrative—not Callgoose defaults.
PRIORITY-AWARE RESPONSE
Critical incidents shouldn't wait in the same queue.
A P1 outage and a low-priority service request need different response expectations. Define thresholds that reflect impact instead of enforcing one timer across everything.
Stricter acknowledgment windows for the incidents that matter most.
Resolution limits tailored to priority and operational needs.
Policy values can change when an incident priority changes.
| Priority | MTTA target | MTTR target | Retrigger |
|---|---|---|---|
| P1 · Critical | 5 min | 45 min | 10 min |
| P2 · High | 10 min | 2 hours | 15 min |
| P3 · Medium | 20 min | 4 hours | 30 min |
| P4 · Low | 45 min | 8 hours | 60 min |
| P5 · Planning | 60 min | 12 hours | 0 · disabled |
Example configuration only. Your organization can choose its own thresholds.
Threshold inheritance · Illustrative structure
Service-level policyMost specific policy when configured and permitted
↓ otherwise, inherit from the team
Team-level policyApplies to services without their own permitted configuration
↓ otherwise, inherit from the workspace
Global policyWorkspace-wide default and override governance
Admin control stays intact. A global administrator decides whether teams can override inherited settings. Without permission, Global policies remain authoritative.
FLEXIBLE GOVERNANCE
One standard across the business. Room for each team.
Use global thresholds for consistency across the workspace, then allow eligible teams and services to configure their own response requirements where needed.
Workspace-level standards managed by Global Admins.
Optional team and service overrides under admin control.
Clear inheritance so users know which policy applies.
ESCALATION THAT FOLLOWS THROUGH
The threshold is the trigger. Your people are the response.
SQIBS connects timing-based breach detection to its existing escalation and notification capabilities, helping the right responders act when acknowledgment or resolution is delayed.
High-urgency notifications
Threshold breaches can activate high-urgency notification rules and the corresponding escalation policy.
Reach people where they work
Use the platform's configured channels—including phone, SMS, email, mobile notifications and collaboration integrations.
Persistent follow-up
When an incident remains unresolved after MTTR, retriggering can help keep it from fading into the background.
TWO FEATURES. TWO DIFFERENT JOBS.
Operational response timers aren't the same as SLA compliance.
Use each feature for its intended purpose. They work independently and can be configured together.
Incident Response Threshold
For everyday operational discipline. Keep acknowledgment and resolution within priority-based time limits.
- MTTA and MTTR breach timers
- Priority P1–P5 thresholds
- High-urgency breach escalation
- Optional MTTR retrigger intervals
- Works without SLA Tracker
SLA Tracker
For service-level commitments. Monitor compliance and available downtime against your configured SLA targets.
- SLA percentage and uptime measurement
- Accumulated downtime tracking
- Reporting and downtime allowances
- Pre-breach SLA notifications
- Independent compliance calculations
SLA setup can optionally populate incident threshold values as a one-time configuration step; the two engines do not continuously synchronize.
FREQUENTLY ASKED QUESTIONS
Clear thresholds. Clear answers.
Everything you need to understand before making response-time monitoring part of your incident workflow.
Is Incident Response Threshold the same as SLA Tracker?
No. Incident Response Threshold monitors response and resolution deadlines and alerts on breaches. SLA Tracker measures service-level commitments, downtime allowances and compliance percentages.
Can I use it without a contractual SLA?
Yes. It operates independently of SLA Tracker and is useful for internal operational response standards even when there is no formal customer-facing SLA.
Can each team or service have its own response policy?
Yes, when permitted by the Global Admin. Configuration can exist at Global, Team and Service levels; the most specific allowed configuration applies.
What happens when MTTA or MTTR is breached?
SQIBS identifies a threshold-breached incident and triggers configured high-urgency notification and escalation rules. MTTA monitors unacknowledged incidents; MTTR monitors incidents not yet resolved.
What does the retrigger interval do?
Retrigger is an optional repeated notification interval after an MTTR breach while the incident remains unresolved. A value of zero disables it; a nonzero interval must be greater than five minutes.
Can I see threshold breaches in reports?
Yes. Incident Reports provides filters for MTTA and MTTR breach conditions so teams can review delayed acknowledgment and resolution.
Does changing a response threshold change my uptime SLA percentage?
No. Incident Response Threshold and SLA Tracker calculate different things. SLA Tracker can optionally populate threshold settings during initial setup, but changing the threshold afterward does not change SLA computation.
Does this interactive example connect to my workspace?
No. The priority controls and incident timer on this page demonstrate possible configurations using illustrative values; they do not access live data or trigger notifications.
Respond on time. Every time it matters.
Give your team clear incident response targets, reliable breach visibility and an escalation path when time runs short.