Cold Start

A cold start is the slow first request that happens when no ready-to-use instance exists. The platform must start a runtime, load code, open connections, and sometimes warm caches before answering. Later requests reuse the warmed instance and are fast.

Why it matters

Cold starts add latency that averages hide. A serverless function that normally answers in 40 ms might take 800 ms or more on its first call, and those slow requests land on real users after idle periods, deployments, or scale-up. They also distort monitoring: an uptime check that pings once every five minutes may hit a cold instance every time and report slow responses that busy users never see.

Example

request 1 (cold):  1240 ms  (runtime boot + dependency load + DB connect)
request 2 (warm):    38 ms
request 3 (warm):    41 ms

Ways to reduce it:

• Ship smaller bundles and avoid heavy imports at startup.
• Reuse connections outside the request handler.
• Use provisioned or minimum instances if the platform offers them.
• Pre-warm caches after deploys.

Details vary by platform, so check your provider's current documentation.

Common mistakes

• Judging performance from the first request only, or from warm requests only.
• Keeping an instance warm with pings that cost more than the minimum-instance setting.
• Forgetting that cold caches after a restart cause the same effect.

Related

• Autoscaling
• TTFB
• Tail latency
• Cache hit ratio

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.