Reliability Issue Detection: Issues When Production Starts Failing
Last verified on Nov 10, 2026.
What the group is for
Reliability is the question of whether your systems do what users expect. An issue in this group says something is failing, slow, stuck or about to run out: a service logs an error it never logged, a job stops running, a vendor starts throttling you. It is the kind of issue an on-call engineer wants to read first.
Nobody writes monitors for this. The Sazabi agent sets up sensors for your project and keeps them current. Some sensors watch for problems every system can have. Others cover what only your system knows: its events, fields, jobs and vendors. New-error detection handles Novel event and Client errors without a sensor.
What feeds reliability issues
Twenty-eight live signals feed eight categories. "General" means a sensor for problems any system can have. "Your system" means a sensor for the events, fields, jobs and vendors only your system knows.
Detail pages: new error detection, client error detection, regressions and frontend breakage. Signals about wrong data, security and cost feed other issue groups, not this one.
Example: one release, two symptoms
This is an example, not output from a real project. A release changes how the API validates the plan field. On the server, this appears in the logs for the first time:
2026-11-08T09:12:55Z ERROR billing-api upgrade rejected: invalid plan "pro_annual" (account=7710)In the browser, the upgrade button now ends in:
fetch POST /api/billing/upgrade -> 422 (212 ms)Each symptom can open its own issue. The Sazabi troubleshooting docs say distinct symptoms of one root cause can produce distinct issues. You can link both to one component so the status view shows a single degraded service.
What you see in Sazabi
A reliability issue carries a stable name, a short description, a severity of low, medium, high or critical, an optional component and a status. It arrives already investigated: what happened, why and the evidence, so you do not start from a graph. For a sensor, the detection records a signal first and the agent's investigation decides whether it becomes an issue. A harmless detection closes without one.
An issue is open, resolved or ignored, and resolved or ignored issues can be reopened. Each issue keeps a history of created, resolved, ignored, muted, unmuted and updated events with the actor and a timestamp, which is handy in a postmortem. Three controls keep the inbox usable:
- Resolve when the problem is fixed and ignore when it never needed a fix.
- Mute when you know about it and cannot fix it yet. A muted issue sends no still-open reminders and counts the reports it held back.
- Severity-scoped delivery rules, so a shared channel gets only the severities you pick.
Staying informed
An issue opening sends Issue triggered. An open issue that gets worse can send Issue updated, and one that nobody closes sends Issue still open reminders after 1, 2, 3, 7, 14, 21 and 28 days and monthly after that. Personal channels follow your own preferences. Shared destinations such as Slack, Microsoft Teams, a webhook, PagerDuty, incident.io and Rootly follow delivery rules. See PagerDuty for paging setup.
If an issue links to a component, the status page shows it as degraded or outage while the issue is open and as operational once it resolves. That page is in limited release.
What you need
Logs from a production project, plus browser or app telemetry if you want client errors. OpenTelemetry is one route in for backend logs, and the Sazabi Browser SDK is the route for the web. Watch that each source keeps sending on the Intake page.
What it does not cover
Detection reads what your telemetry holds, so a failure that leaves no trace in it is invisible. Reliability signals not listed above are not covered today. Issues are metered, so see pricing.
What Sazabi detects today
There are no monitors or alert rules to write: the Sazabi agent automatically sets up sensors for your project and maintains them over time. Sazabi opens an issue when one fires.
- Novel event: A kind of error that has never appeared before. Example: After a deploy, a new error appears: "failed to save draft: lock timeout".
- Vanished event: Something that normally happens has stopped, while traffic is normal. Example: "Application submitted" events stop at 2:14pm.
- Volume shift: An event's rate jumps or drops far outside its normal pattern. Example: Password reset emails at 6x a normal Tuesday.
- Cardinality jump: A field suddenly has far more distinct values. Example: Thousands of new cache keys per minute.
- Retry storm: The same operation retried in tight loops. Example: One background job retried 30 times per record.
- Client errors: JavaScript exceptions, failed fetches and hydration errors. Example: A new TypeError on one page after a release.
- Web vitals regression: Page load and responsiveness get worse. Example: Interaction latency doubles on one page.
- Segment-specific behavior: Only one browser, OS, app version, region or customer is affected. Example: Only Safari 18 users fail checkout.
- Post-deploy shift: Any other signal that starts within minutes of a deploy, tied to the commit. Example: A novel event plus a funnel drop 4 minutes after a release.
- Gradual latency drift: Slow creep over days or weeks that no one notices. Example: Search gets 5% slower every week.
- Latency step change: A sudden jump in latency. Example: Page load goes from 300ms to 1.2s after a deploy.
- Tail latency: Only the slowest requests get worse. Example: p99 triples while the median is flat.
- Boot and cold-start creep: Services take longer to start. Example: Deploys take 3x longer to become healthy.
- Queue wait growth: Work waits longer before it starts. Example: Emails sent 20 minutes after the trigger.
- Approaching a limit: Cloud quotas, burst credits, API rate limits, file handles or plan limits run low. Example: File system burst credits draining, which later shows up as slow boots.
- Saturation: CPU, memory, connection pools, thread pools or disk near full. Example: Database connection pool at 95% during peaks.
- Backlog growth: A queue grows faster than it drains. Example: Job queue grows for 6 hours straight.
- Missed schedule: A cron job didn't run, ran twice or ran long. Example: Nightly export skipped on Sunday.
- Crash loops: Restarts, out-of-memory kills and failing health checks. Example: Worker restarts every 12 minutes.
- Cloud provider errors: Throttling or errors from AWS or GCP APIs. Example: S3 slowdowns during uploads.
- Vendor degradation: Errors or latency from a provider you depend on. Example: Payment API latency triples.
- Webhook gap: Expected inbound webhooks stop arriving. Example: No email delivery events for an hour.
- Vendor rate limiting: A vendor throttles your requests. Example: 429s from your LLM provider at peak.
- Contract change: A vendor's response shape changes. Example: A field your code relies on starts arriving empty.
- LLM behavior drift: Model outputs change: length, refusals, malformed JSON or token use. Example: Structured output parse failures go from 0.1% to 4%.
- Empty output: Jobs report success but produce nothing. Example: Daily digest job sends zero emails.
- Stale data: Caches and sync jobs stop refreshing. Example: Directory data is three days old.
- Service went quiet: A source stops sending logs. Example: The worker fleet goes silent after a config change.
Frequently Asked Questions
What does a reliability issue cover?
Twenty-eight live signals feed it, across outages, silent failures, regressions, slowness, capacity, background jobs, dependencies and frontend breakage. Most come from sensors the Sazabi agent sets up for your project, and two come from new-error detection.
Do I write alert rules for reliability?
No. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. When a sensor fires, the agent investigates and opens an issue if the problem is real.
How do I keep reliability issues from flooding a channel?
Add a severity condition to the delivery rule, for example high and critical only. You can also match by component or owning team. Select each severity you want, because selecting high does not include critical.
Can reliability issues show up on a status page?
An issue linked to a component moves that component to degraded or outage while the issue is open. The component status page is in limited release.
Sources
- Issue contents, severity, lifecycle, suppression of recurrences (accessed Nov 8, 2026)
- Component status derived from linked issues, degraded and outage, seven day timeline, limited release (accessed Nov 8, 2026)
- Issue triggered notification, personal and shared channels, delivery rules (accessed Nov 8, 2026)
- Signals, issues and the agent investigation that links them (accessed Nov 8, 2026)
- Checking that each source keeps sending data and planning for metered issue usage (accessed Nov 8, 2026)
- Distinct symptoms of one root cause can produce distinct issues (accessed Nov 8, 2026)