How Superintelligence Works | Agent Alert Fatigue

Agent alert fatigue occurs when monitoring produces more interruptions than people can meaningfully investigate. An alert that repeats the same harmless event fifty times may look like excellent coverage, yet make a serious unauthorised tool action easier to miss. Effective monitoring distinguishes user-impacting failures from routine events, groups symptoms caused by one incident, routes only actionable pages to the right owner, and preserves quieter reports for slower review. The objective is not fewer alerts at any cost: it is faster recognition and safer resolution of what matters.

The practical method starts with the user’s service-level objective and the actual consequences of errors. Then define reliable measurements, page and ticket thresholds, grouping keys, event provenance, accountable runbooks and a sustainable human response budget. This guide works through a fictional eighty-notification laboratory, interprets an illustrative 99.9% SLO and tests a changed-condition overnight incident. Its numbers are original hypothetical teaching data, never a measurement of eduKate operations or proof that artificial superintelligence exists.

This is a specialist continuation of How Super Intelligence Works. The service-level objective chapter explains error budgets, and incident response covers remediation. This article concentrates on the human decision in between: which warning deserves an immediate interruption, which can become a ticket, and how to avoid exhausting the people responsible for keeping an AI-assisted system trustworthy.

Choose a reading route

Responding to a real alert? Start with actionable pages, grouping and the runbook.
Designing monitoring? Study SLO definitions, burn-rate windows and missing telemetry.
Learning Mathematics? Work through the eighty-notification table and error-budget calculation.
Responsible for people? Focus on reviewer capacity, accessibility, privacy and consequences of missed signals.

1. An alert is a request for human attention

An event is a fact recorded by a system: a timeout, denied permission, completed task or unexpected resource revision. A metric summarises events over a defined population and interval. An alert applies a rule to observations and may ask somebody to act. A page interrupts a person’s current activity; a ticket queues work for normal handling. These are different objects, and counting them all as incidents destroys useful context.

Imagine a fictional school-helpdesk agent checking five source endpoints. One source becomes unavailable and each agent run produces three tool errors. A thousand runs can yield thousands of error events while the underlying problem remains one unavailable source. Paging a teacher or engineer for each event would overwhelm them without improving the source. The alert needs to represent the affected user task and probable shared cause.

The right response depends on consequence. A failed optional image preview might justify a support ticket. An unauthorised attempt to send private student information may require immediate containment even if it happened once. A stale timetable might need its publication held and the source rechecked. Choose the urgency based on real impact, reversibility, affected users and what a responder can change now.

Do not let a model-generated severity adjective become the final page rule. A language model may say ‘critical’ because the wording seems alarming, or ‘resolved’ because it prefers a reassuring conclusion. Build paging decisions from trusted tool states, meaningful measured conditions and accountable policy. The model may help summarise evidence, but it cannot make an unverified external operation safe by choosing a softer phrase.

Return to contents or continue to Start with the user-facing service objective.

2. Start with the user-facing service objective

A good alert begins with a question the user would recognise. Can the assistant deliver an accurate, authorised answer within the intended window? Can it preserve a private draft without exposing another account? Can a human review a consequential action before execution? A CPU graph or model latency trace is useful supporting evidence, but it may not prove a user’s task succeeded or failed.

Google’s SRE guidance recommends alerting on service-level objectives and symptoms instead of paging on every possible internal cause. One database can be unavailable while a legitimate alternate path still serves the task. Another component can report healthy while the agent claims a publication that never happened. The alert should reflect an outcome the service contract actually promises, with technical signals to assist investigation.

Select a small number of indicators that connect to user consequences. They may include verified task-completion rate, unauthorised action attempts, unresolved external effects beyond an agreed window, citation validity for a high-consequence task or long-tail user delay. A response generated quickly is not necessarily a valid completion. Define the numerator, denominator and observation interval before using the metric in an alert.

A monitoring policy should preserve legitimate safe stops. When a user has not approved sending a message, declining to send is correct, not an availability failure. When an official source is absent, abstaining can be the proper result. If the SLO counts every deliberate safety refusal as an error, the system will create pressure to bypass protections. Define accepted terminal outcomes and actual service failures separately.

Return to contents or continue to Separate paging, tickets and logs.

3. Separate paging, tickets and logs

Pages are expensive because they interrupt humans who may be sleeping, teaching or investigating something else. Reserve them for conditions requiring near-term action with an identified owner. A ticket can hold meaningful but less urgent maintenance or a low-rate source-quality problem. Ordinary logs preserve evidence for audits and trends without asking for immediate interruption. These channels should have distinct acceptance rules.

A nonurgent metric can become urgent when it affects a critical user deadline. For example, one stale information source may be repairable next morning, but a current admissions submission window might need an accountable response immediately if users are receiving wrong dates. Conversely, a noisy trace collector warning at midnight may not justify waking an operator when user outcomes and the security boundary remain unaffected.

Routing matters as much as thresholds. A security access violation, a model-quality concern and a broken storage service may require different teams, even when they occur in the same agent workflow. The page should identify the responsible responder, not merely broadcast to every subscribed person. Broadcast noise creates duplication of work, ambiguous ownership and a reason for people to mute the channel.

One useful question is, ‘What can the person do on receipt of this page?’ If there is no runbook, no current evidence and no authorised control the recipient can operate, the page is likely poorly designed. It may need to become an engineering ticket until a reliable response path exists. This does not reduce accountability; it makes the need for an actual intervention mechanism visible.

Return to contents or continue to Deduplicate by incident, not by English wording.

4. Deduplicate by incident, not by English wording

An alerting system may receive similar messages with slightly different text because two model calls phrased the error differently. Free-form text alone is an unreliable grouping key. Use stable service, dependency, failure mode, source revision and affected task population where available. If several downstream agents all fail because one source database is unavailable, group the symptomatic alerts under a shared incident while retaining individual task outcomes for repair.

Deduplication must not erase important distinctions. A private-data disclosure and an ordinary timeout on the same service may need separate incident paths. Two security violations affecting different tenants might have distinct response and notification obligations. Good grouping preserves severity, permission context and affected population, rather than silencing everything with a shared service name.

Maintain a parent incident with child observations. The parent carries current owner, investigation status, impact, next action and resolution evidence. Child observations retain the exact time, task and technical evidence. This allows one page to represent a storm of duplicate symptoms without deleting forensic detail. If the incident expands or changes character, the parent can be reclassified under accountable rules.

A recovery message also needs deduplication. A flapping dependency may oscillate between healthy and unhealthy measurements every minute. Sending a new ‘resolved’ and ‘critical’ notification each time can exhaust operators. Alert systems such as Prometheus include waiting and keep-firing controls to manage transient changes; those settings must be chosen in context and cannot replace a genuinely accurate service-impact measure.

Return to contents or continue to Use time windows that fit the failure.

5. Use time windows that fit the failure

An instant error-rate threshold can react quickly but also page on a short harmless burst. A long averaging window is steadier but can delay detection of a serious incident. Alert design balances detection delay, precision, reset behaviour and the consequences of a missed failure. No universal five-minute threshold suits every agent. User deadlines, traffic volume and permitted response time matter.

Prometheus alerting rules have a `for` duration that requires an expression to remain active before an alert starts firing. Its `keep_firing_for` duration can prevent rapid resolution and reactivation during brief data gaps or oscillations. These are useful implementation tools, not proof that a particular page corresponds to a genuine incident. The underlying expression and reliable data source still need careful design.

Multi-window burn-rate alerts can capture fast severe degradation and slower sustained budget consumption. Google SRE’s alerting-on-SLO guidance explains why a single threshold may have unacceptable precision or recall for particular failure patterns. A high short-window burn can justify urgent action, while smaller prolonged budget consumption may be a ticket. Adapt the actual policy to the service rather than transplanting one example unchanged.

Some events should bypass ordinary smoothing. A confirmed unauthorised publication, privacy leak or revocation bypass can matter even as a single case. Treat such outcomes as direct critical signals with suitable verification and emergency controls. Do not wait for a statistical window to accumulate more incidents merely so a threshold looks mathematically impressive.

Return to contents or continue to An illustrative 99.9% objective.

6. An illustrative 99.9% objective

Assume an entirely fictional service with an SLO that 99.9% of a defined class of valid user tasks completes correctly during its measurement period. The allowed error ratio is 1 − 0.999 = 0.001, or 0.1%. If 500,000 eligible tasks arrive under a simple count-based budget, one thousandth of 500,000 is 500 tolerated errors. This arithmetic depends on the chosen indicator and denominator; it is not a claim about a real provider.

Suppose an illustrative 50,000-task subwindow has 400 actual defined service errors. Its error fraction is 400 ÷ 50,000 = 0.008, or 0.8%. Compared with the 0.1% objective allowance, the burn rate is 0.8 ÷ 0.1 = 8. This means the subwindow’s error rate is eight times the long-term allowed ratio under the exercise. It does not, by itself, establish a particular page severity without the reporting duration and response policy.

An error budget and an alert count have different units. The fictional window contains 400 erroneous tasks, but one root incident could have caused most of them and generated thousands of log events. Paging for every task would convert a genuine service problem into an unmanageable interruption storm. The useful alarm identifies the budget-consuming condition and a responder who can change it, while task records support later reconciliation.

Changing the SLO definition can change the arithmetic dramatically. Excluding legitimately refused unauthorised actions may be correct, while excluding failed permitted tasks simply to improve the rate is not. If a status becomes Unknown after a lost tool receipt, the system must define whether and when it counts as service failure. Keep versioned definitions and explain any comparison that spans a metric change.

Return to contents or continue to Worked laboratory: eighty notifications.

7. Worked laboratory: eighty notifications

Imagine a fictional education-helpdesk alert stream that generates eighty notifications during an invented shift. Twenty-five correspond to distinct actionable incidents requiring timely human response. Thirty are repeat notifications from incidents already represented by those twenty-five. Fifteen concern lower-priority maintenance suitable for tickets, and ten cannot yet be classified because supporting evidence is missing. These reporting categories are mutually exclusive and sum to 25 + 30 + 15 + 10 = 80.

The raw actionable-notification fraction is 25 ÷ 80 = 31.25%. The duplicate fraction is 30 ÷ 80 = 37.5%, tickets are 15 ÷ 80 = 18.75%, and unclassified notifications are 10 ÷ 80 = 12.5%. The percentages add to 100%. They describe this deliberately constructed notification stream, not the prevalence of real system defects or the accuracy of the AI model itself.

If the thirty duplicates are grouped correctly, the incident stream might present twenty-five primary actionable pages, fifteen tickets and ten still-unclassified records. That is fifty distinct attention or investigation records rather than eighty notifications, assuming grouping did not conceal a separate urgent problem. Fewer displayed items are not proof of fewer user errors: the underlying affected task count must still be measured.

Do not classify the ten unknown cases as harmless merely because the responder is busy. An unknown could involve a missing source trace, an unverified tool result or a malformed record. Give it an owner and a deadline for investigation. A real critical signal can hide in poorly classified monitoring data, making evidence completeness part of the alert-quality contract.

Return to contents or continue to Precision, recall and rare critical incidents.

8. Precision, recall and rare critical incidents

Alert precision asks which selected pages actually corresponded to the defined actionable condition. Recall asks how many such conditions were detected among all that occurred within the evaluated population. A dashboard showing a lower number of pages cannot establish improved precision without a reviewed reference set, and it cannot establish recall without checking for missed incidents. Both questions require more than a count of messages sent.

Suppose a separate fictional audit finds forty genuine actionable incidents, thirty-six paged correctly and four missed. The detection recall is 36 ÷ 40 = 90%. If fifty pages fired, with thirty-six genuine, precision is 36 ÷ 50 = 72%. These are invented teaching values, not conclusions about an actual alert system. A team needs to consider whether those four misses included high-impact safety events rather than celebrate a single aggregate score.

False pages have real human cost, yet indiscriminately suppressing them can increase missed severe incidents. Risk-aware design uses distinct conditions for rare critical failures and for ordinary fluctuations. A verified unauthorised external action should not be made invisible because an unrelated error rate is low. A harmless transient parsing delay may not need immediate paging despite many logs.

Review labels need calibration too. Two operators may disagree whether a particular notification was actionable at the time, especially when the response path was unclear. Preserve the event state and available evidence, adjudicate against predeclared criteria, and change a runbook where necessary. Do not overwrite original labels just to make alert-precision trends appear smoother.

Disposition	Notifications	Share
Actionable distinct incidents	25	31.25%
Repeated symptom notifications	30	37.50%
Ticket-only work	15	18.75%
Evidence still missing	10	12.50%
All notifications	80	100.00%

Fictional helpdesk monitoring exercise, not real incident statistics or AI performance.

Return to contents or continue to The human cost of an interruption.

9. The human cost of an interruption

One page can require the responder to stop complex work, build context, investigate and later recover their concentration. Several duplicate pages can amplify this burden without adding information. Google’s SRE on-call guidance warns that poorly configured alerts create operational overload and that fatigue can cause serious alerts to receive less attention. The design question is therefore not only computational; it involves the limits of human review.

An automated agent may be able to classify thousands of traces quickly, but it cannot manufacture a human’s sustained attention. If every ambiguous model output is escalated, the review queue may expand beyond staff capacity. Define which conditions merit urgent intervention, which need sampled review and which can wait. A high queue throughput metric is not evidence that individual decisions are understood or authorised.

Alert fatigue is not a reason to remove human oversight altogether. If a particular consequence requires meaningful human approval, an operator should receive enough relevant evidence and time to decide. Reduce repetitive low-value notifications, group common errors and give reviewers actionable context. The goal is to protect scarce attention for decisions where it actually matters.

Be cautious about making claims about psychological effects beyond the available evidence. Different people and teams respond to interruptions differently. The durable operational facts are that paging consumes time, repetitive toil can overload a team and misconfigured monitoring can obscure serious issues. Measure those mechanisms locally with appropriate privacy and workplace care rather than labelling an individual inattentive.

Return to contents or continue to A page needs a working runbook.

10. A page needs a working runbook

Each high-urgency page should identify the affected user task, likely failure domain, evidence location, current owner and first safe diagnostic step. A responder needs to know which actions are authorised: can they disable one tool, pause new writes or switch a read-only fallback? A page that contains only ‘agent error’ may generate an investigation from scratch every time.

Write runbooks for observed states rather than generic reassurance. ‘Provider response unknown’ means inspect the original operation ID and target service before retrying. ‘Unauthorised tool command refused’ means verify the refusal and investigate its source, not broaden the credential. ‘Source revision stale’ means hold consequential advice and fetch the appropriate current official record. The runbook should direct the right check without inventing an outcome.

Escalation must be explicit. A first responder may diagnose a storage outage but lack authority to approve an education-policy correction. The system should identify when a domain expert or privacy owner is required. Preserve the original event evidence and pending user tasks across handoffs. One accountable incident owner prevents three well-meaning agents or people from applying conflicting repairs.

Test the runbook using controlled scenarios. If a staff member cannot find the relevant task ID, the page design is incomplete. If an automated pause control cannot actually stop new writes, the recovery instruction is unsafe. If the source has recovered but the page says everything is fixed before readback, the status definition needs repair. Practice reveals the gap between a polished document and a usable procedure.

Return to contents or continue to Alert routing must respect privacy and authority.

11. Alert routing must respect privacy and authority

Monitoring records can contain user messages, source excerpts, identities and tool parameters. The recipient of a page usually needs enough information to investigate without receiving every private field. Use stable task and incident references, affected service and a secure route to detailed evidence. A shared paging channel should not become an unregulated archive of children or families.

Different failures require different privileges. A reviewer who checks an educational claim may need a cited official syllabus. A security responder may need an access-log event but not a learner’s full conversation. The agent should not attach arbitrary untrusted tool output to a page that a busy operator might treat as instructions. Source content is evidence, not a new authority grant.

Response actions also require permission. A monitoring agent can propose turning off a connector, but the controlling service must enforce appropriate approval and scope. An overly broad emergency action might stop healthy workflows or expose records through a workaround. Use narrow, logged controls with independent effect checks. A quick fix is not safe merely because it follows a genuine page.

If an alert reveals a potential privacy breach, investigate under applicable organisational and legal requirements. Avoid promising every copy has been erased without checking backups and derived data. Preserve required evidence in a controlled way and separate it from unrestricted chat summaries. An alert is the beginning of accountable response, not proof that containment and communication are complete.

Return to contents or continue to Design for overnight load and staff capacity.

12. Design for overnight load and staff capacity

An on-call rotation should account for how many pages people can realistically investigate and what happens when several critical incidents coincide. An automation that pages one person every minute for minor variation is not sustainable. The response policy may use distinct on-call roles, backup escalation and deliberate batching for nonurgent issues. These organisational decisions should follow the nature of the service and available staff, not a fashionable diagram.

A simple capacity exercise makes the issue concrete. Suppose a fictional shift has twenty actionable cases and each takes an average of twelve minutes of active human analysis. That is 20 × 12 = 240 analyst-minutes, or four hours of hands-on work. The figure excludes waiting for vendors, coordination and repeated context switching. It does not mean every incident will be resolved within four clock hours by one responder.

Now imagine the same twenty incidents generate sixty duplicate pages. If each duplicate requires even a minute of attention, the redundant work adds sixty minutes, before accounting for the cost of interruption. Grouping the notifications could recover attention without changing the true incident count. However, the system must retain the associated task records and avoid hiding a new severe event under an overly broad grouping key.

Capacity planning needs honest failure states. If the number of actionable incidents exceeds what the team can handle, the system might pause optional operations or route them to a safe queue. It must not automatically approve consequential AI actions just to reduce the backlog. Safety-critical approvals and human capacity are linked; a smaller permitted task scope may be preferable to overwhelmed reviewers.

Return to contents or continue to Change of scenario: a single severe event.

13. Change of scenario: a single severe event

Transfer the method to a fictional agent that drafts student-support messages. Over one hour, forty routine monitoring notifications appear from a failing image-preview service. At the same time, one separate access-control check detects an attempted send to an unapproved recipient. The preview failures may be grouped as one lower-urgency incident if core work remains safe, but the unauthorised-send attempt requires its own security handling regardless of its rarity.

Counting forty versus one is not a severity ranking. The single rejected send might indicate a configuration defect affecting other actions, and the responsible person should confirm that the destination refused it. An alert rule based solely on frequency would page for previews and miss the higher-consequence permission event. The task contract and actual effect determine urgency, not the number of nearly identical log messages.

Suppose the team suppresses all notifications from the agent service for thirty minutes because the preview warnings are annoying. This could conceal the independent access-control signal. A better design silences or groups the specific diagnosed low-impact rule while preserving other severities and routing. Silences need scope, expiry and ownership; an unexplained blanket mute can become a new incident.

Now change one fact: the provider’s tool result is ambiguous, so the send might have occurred despite the local guard’s reported denial. The response must reconcile the external operation before claiming safety. The monitoring system should preserve an unresolved state and page the appropriate owner based on the consequence. An AI-written message that ‘nothing happened’ is not sufficient evidence.

Return to contents or continue to Tune windows by verified outcomes.

14. Tune windows by verified outcomes

Threshold tuning should begin with labelled incidents and real user outcomes. Compare which conditions fired, which true incidents were missed and how quickly responders could act. If a new short-window alert catches early serious failures but causes harmless pages every morning, refine its signal or ownership. Do not improve the dashboard simply by discarding inconvenient examples.

Add canary and change annotations. A new model, tool connector or source-retrieval policy can change error patterns. Mark when the software changed and test whether alerts still reflect the same user job. A rising count of expired approvals may indicate safer enforcement rather than worse service. A rise in completed-but-unverified tasks may reveal a broken readback pipeline. Interpret trends through evidence, not just colours.

Google’s SLO guidance gives examples of multi-window burn-rate alerting, but those numbers are starting points within its service context. A small educational workflow with low traffic can have very different sampling noise and human urgency than a high-volume web service. Apply the underlying reasoning about budget consumption, detection time and actionability rather than copying a threshold into every project.

Schedule review of alert rules after meaningful incidents. Ask which page helped, which merely repeated information and which missing signal prolonged harm. Tie each change to a measured hypothesis and preserve earlier definitions for trend comparison. An alerting system should learn from evidence, but it should not silently turn off controls that protect user privacy or authorisation.

Return to contents or continue to Accessibility makes incident response possible.

15. Accessibility makes incident response possible

A page that can only be understood from a red dashboard may be unusable for a responder relying on a screen reader or phone notification. Use meaningful event titles, textual severity explanations, real task IDs and a clear action route. Do not rely on colour or a tiny icon as the sole description of risk. Accessibility matters because a delayed human decision can leave an AI task in an unsafe state.

Long dense payloads can also obscure the critical fact. Put the immediate user consequence and first safe action near the top; provide source and tracing details through an access-controlled link. An operator should not need to decode an entire model transcript just to learn that a message may have been sent without approval. Brevity is helpful when it preserves, rather than hides, decisive evidence.

Human oversight can require a pause before irreversible action. The monitoring interface should make that pause accessible, accurately confirm whether the relevant service accepted it and provide a route if the command’s result is unknown. The presence of a button does not establish that the operator can perform or verify the action. Test the whole decision journey, including remote access and unexpected errors.

Make correction and appeal routes visible to affected users as well. A parent may report a wrong education deadline before monitoring detects it. The complaint should reach an accountable reviewer with appropriate source context. Treat such feedback as evidence for investigation, not automatically as proof that the model was wrong or right. Accessible recourse is part of reliable alerting, not an unrelated customer-service ornament.

Return to contents or continue to Measure improvements without gaming the count.

16. Measure improvements without gaming the count

A reduction from eighty notifications to fifty grouped records can free human attention while preserving the same underlying incidents. That is good if no meaningful signal was lost. It would be bad if the apparent improvement came from disabling the error collector or dropping high-severity events. Report grouping coverage, missed incidents, response delay and user outcome changes alongside raw notification count.

Use unique task and incident identifiers to relate several pages to one cause. A user-facing task may fail three times during a dependency outage while another task safely refuses an unauthorised action. They require different outcome labels. Counting retries as independent successful recoveries can artificially improve response metrics; counting safe refusals as failures can encourage bypasses. Correct denominators are essential.

Response time alone does not prove resolution. An operator might acknowledge a page immediately but spend hours repairing the underlying source or reconciling a possibly completed external operation. Measure time to verified containment and time to safe restoration separately from time to acknowledgement. An AI summariser can help produce an incident narrative but should not declare the issue closed before authoritative checks support it.

An alert programme is successful when users experience fewer harmful unresolved states and responders can address the remaining ones without constant unnecessary interruption. The metric must therefore connect technical signal, authorised response, real task outcome and human workload. No single accuracy or page-count percentage captures that whole chain.

Return to contents or continue to Diagnose five monitoring failures.

17. Diagnose five monitoring failures

Failure one: every tool timeout creates a separate critical page. Repair by grouping on shared cause while retaining precise task evidence, adding an actionable incident owner and preventing a retry storm. Failure two: the alert relies on model-generated statements of success. Repair by using the actual provider or storage state and preserving Unknown when no receipt exists.

Failure three: a rule pages for harmless source latency but ignores a confirmed unauthorised external action. Repair the severity taxonomy and establish non-compensatory critical signals based on user consequences. Failure four: the same person receives alerts from three unrelated services with no ownership route. Repair routing, role separation and escalation.

Failure five: a production change breaks the telemetry pipeline, making every graph appear green because no data arrive. Treat missing required evidence as an observable issue rather than zero errors. A monitoring system should detect its own inability to see critical events, with a suitable alert designed not to recurse into infinite false pages.

After each repair, replay the original failure scenario in a safe environment, test nearby variations and independently check the result. Do not disable necessary privacy, consent or human-approval controls to make the alert counter smaller. The end point is a trustworthy service, not a quiet notification feed.

Return to contents or continue to Limits and the practical first step.

18. Limits and the practical first step

No monitoring rule can guarantee that every harmful AI action will be detected immediately. Data may be missing, signals may correlate and people may misunderstand a page. A finite sample of quiet shifts cannot prove rare-event coverage. State the known limitations, keep a correction path and use independent checks for consequential operations.

Monitoring also consumes resources. Collecting every model message, tool argument and private document may be costly and intrusive. Prefer structured metadata, bounded tracing and controlled evidence access. Preserve enough information for accountability without turning an incident dashboard into a broadly readable archive of learners’ personal details.

For learners, practise by dividing 400 errors by 50,000 tasks and comparing the result to a 0.1% SLO allowance. Then classify eighty fictional notifications into actionable, duplicate, ticket and unknown categories. Change one condition from harmless preview failure to an unapproved send and explain why the correct alert decision changes despite lower frequency.

For builders, begin with one real user-facing objective, a small set of independently verified failure signals and runbooks that an operator can actually execute. Group redundant notifications, separate tickets from pages, review missed incidents and record human workload. Expand monitoring only when the additional signal contributes to a clearer or safer next action.

Return to contents.

Frequently asked questions

Should an agent page someone for every error?

No. The relevant question is whether the event threatens a user-facing objective or critical safety boundary and requires an actionable response now.

Does reducing pages always mean better reliability?

No. Grouping redundant symptoms can help, but suppressing real incidents or losing telemetry can make a system dangerously quiet.

How is alert fatigue different from queue starvation?

Alert fatigue concerns overwhelming human attention; starvation concerns tasks repeatedly failing to receive service. Both can interact but need distinct measurements and remedies.

What is an error-budget burn rate?

It is the observed error rate relative to the permitted error ratio under a declared service-level objective, with time windows and population definitions that matter.

When is one event enough for urgent attention?

A verified high-impact permission failure, privacy exposure or other critical action can justify immediate handling without a large statistical sample.

Can an AI summariser close an incident by saying it is fixed?

No. Closure should follow authoritative observations of affected resources and required user outcomes, with unresolved external effects left explicit.

Source notes

Sources reviewed 24 October 2026. Alert counts, incident categories, SLO workload and staffing calculations are invented solely for reader practice, not measurements of an actual eduKate system.

Google SRE Workbook — Alerting on SLOs: Error budgets, burn-rate windows, detection and paging trade-offs.
Google SRE — Being On-Call: Human operational load and the need for actionable paging signals.
Google SRE — Identifying and Recovering from Overload: Workload, interruption and system-health consequences of overloaded human responders.
Prometheus Alerting Rules: `for`, `keep_firing_for`, alert labels and active/firing semantics.
Google SRE — Eliminating Toil: Sources of repetitive reactive work and strategies for prevention.
NIST AI RMF Playbook — Manage: Incident response, monitoring, governance and feedback considerations.

How Superintelligence Works | Agent Alert Fatigue — Actionable Pages, Signal Noise and Reviewer Capacity