Crash Loop Alerts: An Investigated Issue When a Service Keeps Restarting
Last verified on Nov 10, 2026.
What it catches
A crash loop is a process that starts, fails and gets started again. The service runs below capacity the whole time, and each restart wipes the state that would explain the failure.
The Sazabi agent sets up sensors for your project and maintains them over time. Crash loops is one of the signals it writes for you. It watches for:
- A worker that exits with a fatal line every few minutes.
- A container killed for running out of memory, then restarted, then killed again.
- A health check that keeps failing, so the platform keeps replacing an instance that was never going to pass.
- A service that boots fine on yesterday's build and dies on startup after a config or secret change.
Example: a missing secret after a deploy
This is an example, not output from a real project. A new build of billing-worker ships at 09
2026-11-08T09:12:03Z INFO billing-worker starting version=2026.11.07-3
2026-11-08T09:12:09Z ERROR billing-worker fatal: config load failed: WEBHOOK_SECRET is empty
2026-11-08T09:12:09Z INFO platform: billing-worker exited code=1, restarting
2026-11-08T09:14:21Z INFO billing-worker starting version=2026.11.07-3
2026-11-08T09:14:27Z ERROR billing-worker fatal: config load failed: WEBHOOK_SECRET is empty
2026-11-08T09:14:27Z INFO platform: billing-worker exited code=1, restartingThe sensor behind this signal might ask: "Has any service started again and again in a short time?" Each service is judged on its own, so billing-worker stands out while everything else stays quiet.
An issue could look like this:
- Name: billing-worker restarting on every start with an empty WEBHOOK_SECRET
- Description: Since 09 UTC the worker has started and exited repeatedly. Every start logs the same config load failure. The first bad start matches the 09 deploy.
- Severity: high
- Component: billing-worker
How Sazabi sets it up
You set nothing up. Restart behavior depends on where and how you run things, so the agent reads your logs to find what a start looks like, what an exit or kill looks like on your platform, and which services restart. It writes and maintains the sensor.
When you rename a service or change how it logs its startup, the agent keeps the sensor current. A worker that restarts nightly by design is not treated like one that restarts every two minutes.
What you see and how you get told
A firing records a signal and starts an investigation. The investigation ends one of two ways: an issue if the loop is real, or no issue if the restarts were harmless. The issue arrives with the agent's account of what happened, why and the evidence, so you open it knowing the exit reason instead of starting from the restart count.
To see the raw signals, run sazabi signals list --type sensor. Notifications follow your own settings and any delivery rules for shared channels, which can match on severity, component or owning team. A platform team can take every high issue on billing-worker while others see only their own services. You can also ask follow-up questions in the issue thread, or run sazabi issues agent-prompt to hand the fix to a coding agent.
What you need
The restart evidence has to be in logs you send to Sazabi: your application's startup and fatal lines, and whatever your platform logs about exits and kills. Connect a cloud platform such as AWS or send logs through OpenTelemetry. Whether your platform writes restart and kill events to a log stream is a platform setting, so check that first.
What it does not cover
- It reads logs, not cluster state. A restart that leaves no line anywhere is invisible.
- It does not detect the config or flag change that caused the loop. The agent may point at one in its analysis if your logs show it.
- It does not restart, scale or roll back anything.
- Slow memory growth before the kill is a different question from the loop itself. The reliability issues page lists what Sazabi covers in that area.
Related
The vendor-neutral write-up is the guide to detecting crash loops. If the loop starts because a provider errors, see cloud provider errors. A first-ever startup failure is also a new kind of error, which new error detection covers. Issues detected 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.
- Crash loops: Restarts, out-of-memory kills and failing health checks. Example: Worker restarts every 12 minutes.
Frequently Asked Questions
Do I write a restart alert for each service?
No. The Sazabi agent sets up sensors for your project and maintains them over time. It reads your logs, sees which services restart and how that shows up, and writes the crash loops sensor. You write no query. You can ask support for a specific sensor in plain words.
Does Sazabi read my orchestrator directly?
It works from the logs you send. If your platform writes restart, kill or failed health check lines to a log stream you have connected, the sensor can see them. If a restart leaves no line anywhere, there is nothing to read.
Will a normal rolling deploy open an issue?
It should not. A routine rollout is not a crash loop, and the agent writes and maintains sensors so that normal behavior does not open issues.
Does one broken dependency produce an issue per service?
Each service is judged on its own, so one looping service does not hide in totals. The issue analysis is where the shared cause shows up, such as one upstream outage taking several workers down at once.
Sources
- What an issue carries, severity levels, folding of recurrences, handing an issue to a coding agent (accessed Nov 8, 2026)
- Issue triggered notifications and delivery rules by severity, component and owning team (accessed Nov 8, 2026)
- Listing sensor signals with the CLI (accessed Nov 8, 2026)