Cold Start Creep Detection: An Issue When Services Take Longer to Start

Last verified on Nov 10, 2026.

What it catches

A service that boots slowly makes everything around it slower: deploys take longer, autoscaling reacts late, and a restart after a crash leaves a gap in capacity. Boot time rarely jumps. It creeps, a few seconds per release, until a rollout that took two minutes takes ten. Typical causes:

• A container image keeps growing with each dependency.
• A start-up step loads a larger cache or warms a bigger model.
• Migrations or seed work run on every boot.
• A function's bundle gets heavy enough that its first request waits.
• A credit or quota underneath the platform runs dry, and boots slow down as a result. See approaching a limit.

Example: workers take longer to report ready

This is an example, not output from a real project. A worker service logs when it starts and when it is ready to take jobs. Three deploys, a few weeks apart:

2026-10-02T14:03:10Z INFO worker boot=begin version=2026.10.02-1 host=w-7
2026-10-02T14:03:49Z INFO worker boot=ready version=2026.10.02-1 host=w-7 ready_after_ms=39100
2026-10-23T09:41:02Z INFO worker boot=begin version=2026.10.23-2 host=w-3
2026-10-23T09:42:11Z INFO worker boot=ready version=2026.10.23-2 host=w-3 ready_after_ms=68800
2026-11-06T17:22:40Z INFO worker boot=begin version=2026.11.06-1 host=w-5
2026-11-06T17:24:35Z INFO worker boot=ready version=2026.11.06-1 host=w-5 ready_after_ms=115000

Nothing is wrong in any single line. The trend is the problem. An example issue:

• Name: Worker boots taking longer with each release
• Description: Time from boot=begin to boot=ready for the worker service has grown across the last three releases, on every host.
• Severity: medium
• Component: worker

The agent's analysis would say that the growth appears on all hosts, which points at the release and not a bad node.

How Sazabi sets it up

The Sazabi agent sets up sensors for your project and maintains them over time, and you set nothing up. A startup sequence is specific to your code, so the agent reads your logs to find the lines that mark a start and writes the sensor from them.

In plain words the question might be: "Tell me when the time from boot start to ready goes far above its usual level." The agent keeps the sensor current as your system changes, so a renamed log line should not leave it watching nothing.

What you see

A firing records a signal, and an investigation decides whether it matters. If so, the issue lands in your inbox already analyzed. List the raw signals with sazabi signals list --type sensor.

Startup problems usually belong to a platform or infrastructure team, so delivery rules by component or owning team are worth setting. A repeat while the issue is open folds into it.

What you need

Startup lines in your logs, from your own code or from the platform that runs it. Logs from AWS services, Fly.io or Render are typical sources. For a Lambda-specific read on the logs, see AWS Lambda logs.

Reading the issue

The first thing to check is whether the slowdown is on every host or a few. Every host points at the build or the startup code. A few hosts point at those machines, their disks or their network. The second is which phase grew, if your logs mark phases such as config load, migrations and warm-up. The agent can read those markers and say where the added time sits. Ask it in the thread, and compare with the release before the first slow boot.

What it does not cover

• Slow request handling after a service is up. See latency step changes.
• A service that crashes while booting and never gets ready. That is a crash loop, which is a different detection.
• Boots that never get logged, such as a platform that hides its own startup.
• Blocking a release because boot got slow.

Issues Sazabi detects are metered, so check pricing. For safer release patterns, see blue-green deployment.