notice
watch-streakRepeated watch-zone latency across a short window.
3 samples above watchMs within 5 minutes.Show cockpit notice only.PROVIDER HEALTH LATENCY ALERT READINESS LAYER
Slow once is noise. Slow repeatedly is a signal.
A read-only alert readiness layer that defines when repeated watch, warning, or critical latency should become an escalation candidate before automatic alerting is enabled.
Universal Time Scroll
Every TheoB pathway can move through Past, Present, and Future without losing context.
Present
Read current signals, conditions, and live context.
🎙
Universal Voice Orb
Voice ready
SYSTEM STATE
StableFounder ControlledHuman Reviewed
LATENCY ALERT READINESS
No spam cannon. Define the signal first.
Provider Health Latency Alert Readiness Layer defines when slow-but-healthy routes become escalation candidates. Alerts remain disabled until repeated-sample rules, cooldown windows, trend persistence, and founder-approved channels are ready.
falseAlert Readiness Ready
falseAutomatic Alerting Allowed
3Ready Rules
7Review Required
Latency alert readiness is intentionally not active until repeated-sample rules, cooldown windows, trend persistence, founder-approved channels, and recovery handoff boundaries are finalized.
warning
warning-streakRepeated warning-zone latency across a short window.
2 samples above warningMs within 5 minutes.Show cockpit warning and recommend investigation.critical
critical-spikeCritical latency on a Critical provider route.
1 sample above critical threshold on system-heartbeat or command-center-status.Founder-visible escalation candidate.warning
critical-route-dragMultiple Critical provider routes remain in watch/warning zone together.
3 Critical routes over watchMs during same polling window.Recommend cockpit load review.warning
systemic-latency-dragMost provider routes enter watch or warning zone together.
6+ of 9 routes above watchMs.Recommend polling optimization or provider performance review.review-required
Repeated Watch Events RequiredA single watch-level latency event should not automatically alert. Alerts should require repeated watch-zone samples across a defined window.
3 watch samples within 5 minutesPrevents noisy alerts from one-off slow responses.review-required
Warning Streak EscalationWarning-level latency should become an escalation candidate when it persists across repeated checks.
2 warning samples within 5 minutesHealthy-but-slow routes get attention before they become failures.review-required
Critical Spike EscalationCritical latency should be eligible for immediate founder-visible escalation if it affects a critical route.
1 critical sample on Critical route or 2 critical samples on High routeCritical control surfaces should not drag silently.ready
Criticality WeightingCritical provider routes should have stronger alert sensitivity than high-priority routes.
Critical routes escalate faster than High routes.Founder control and safe-mode surfaces stay prioritized.review-required
Cooldown Window RequiredLatency alerts need cooldown windows so the cockpit does not spam repeated warnings.
minimum 10 minute cooldown per provider/endpoint/classificationAlert fatigue kills operator trust.ready
No Secret CaptureLatency alert readiness may reference provider names, endpoints, timings, and classifications only.
never store request payloads, tokens, cookies, credentials, or private logsPerformance monitoring must not become secret collection.review-required
Trend Persistence DependencyReliable alerting needs trend history, but trend persistence must wait for audit persistence and redaction readiness.
append-only redacted trend store approvedNo database write path until governance allows it.review-required
Founder-Approved Alert ChannelsNotification channels must be approved before alerts are sent externally.
approved channels: cockpit only, email, SMS, Slack, webhook, or future TheoB notification railNo surprise outbound notifications.ready
Recommendation Only Until ActivatedThis layer can recommend alert readiness but cannot send alerts or mutate providers.
manual founder activation requiredObservation and recommendation are not execution.review-required
Recovery Routing Handoff BoundaryLatency alerts may suggest recovery routing, but cannot trigger recovery actions until authority gates are ready.
alert-to-recovery handoff requires founder authority confirmationSlow route detection cannot become automatic production mutation.Allowed NowRender latency alert readiness status.Define future latency alert trigger candidates.Show repeated watch/warning/critical escalation rules.Keep alerting disabled.Keep trend persistence disabled.Use latency watch output manually for review.
Not Allowed YetSend automatic latency alerts.Persist latency trend history.Trigger recovery routing automatically.Auto-disable providers.Send outbound notifications.Store request payloads, secrets, cookies, tokens, credentials, or private logs.
latencyAlertId: stable latency alert idprovider: safe provider labelendpoint: safe route labelcriticality: Critical/High/Medium/Lowseverity: notice/warning/criticalcandidateType: watch-streak/warning-streak/critical-spike/critical-route-drag/systemic-latency-dragsampleWindow: 5m/15m/1hsampleCount: numbermaxLatencyMs: numberp95LatencyMs: numbercooldownStatus: eligible/in-cooldownrecommendedAction: safe text recommendationcreatedAt: ISO timestampproductionMutation: falseredactionStatus: redacted-safe
notificationId: stable notification idlatencyAlertId: linked latency alert idchannel: cockpit/email/sms/slack/webhook/theob-notification-railrecipientScope: founder/operator/reviewerdeliveryStatus: queued/sent/failed/suppressedcooldownApplied: true/falsecreatedAt: ISO timestamp