22

Is there a clear way to identify "cold starts"? Either in runtime in the Lambda itself, or via the logs? I know that cold starts are characterized by longer runtimes, which I can actually see, but I'm looking for a clear cut way. I'm using Node.js if that matters.

Update: There are two good answers below, for two use cases: - Identifying the cold start as the lambda runs. - Identifying the cold start from the CloudWatch log.

Mario Galic
  • 47,285
  • 6
  • 56
  • 98
Bachman
  • 701
  • 1
  • 6
  • 25

3 Answers3

27

If you add some initialization code to the top of your NodeJS script, you will be able to tell in the code that it is a cold start, and you will then be able to log that if you want to see it in the logs. For example:

var coldStart = true;
console.log("This line of code exists outside the handler, and only executes on a cold start");


exports.myHandler = function(event, context, callback) {
  if (coldStart) {
    console.log("First time the handler was called since this function was deployed in this container");
  }
  coldStart = false;

   ...
   
  callback(...);
}

Update:

If you only care about seeing cold starts in the logs, Lambda now logs an extra "Init Duration" value in CloudWatch Logs for cold starts.

Mark B
  • 183,023
  • 24
  • 297
  • 295
  • 1
    While this is good info, I STRONGLY suggest firing CloudWatch Custom Metrics so that you can easily measure and graph this information. – Bruno Bronosky Mar 08 '20 at 00:00
  • @Mark B, how to check the cold start in case of python scripts? – TheCodeCache Mar 29 '20 at 05:40
  • 1
    @Manoranjan there is no difference in the behavior of a Python Lambda function. You would use a value defined outside of the handler function in Python, just like this JavaScript example. – Mark B Mar 29 '20 at 14:39
  • 1
    @SpiritualOverflow, that's almost identical. Set a variable in the Python script for your Lambda function _outside_ the handler function: `cold_start = True`. That code line will run during instance initialization. Then _inside_ a handler function, check whether that variable is set and reset it afterwards: `if cold_start: print("cold_start happened"); cold_start = False`. (Multiple statements on one line aren't really allowed in Python, so make a proper block after the `if` condition.) – Jochem Schulenklopper Sep 19 '20 at 16:57
  • 2
    @SpiritualOverflow, or make a counter for the number of invocations from an instance. Outside the handler functions: `invocation_count = 0`, and inside the/any handler: `invocation_count += 1`. Then you can test on `invocation_count` in the/any handler: if it's zero, your instance was just initialized. If it isn't zero, the instance handled events prior. This is even better than my earlier comment ^ as it'll tell you how many events were handled by an individual instance. I used that trick for this experiment: https://xebia.com/blog/til-that-aws-lambda-terminates-instances-preemptively/. – Jochem Schulenklopper Sep 19 '20 at 17:02
25

As an update, AWS now provide visible info on cold starts in the form of "Init Duration" , inside the Report section of a Cloudwatch Log. The calls that do not suffer from a cold start will not contains this information in the log

Duration: 1866.19 ms Billed Duration: 1900 ms Memory Size: 512 MB Max Memory Used: 163 MB Init Duration: 2172.14 ms

qkhanhpro
  • 4,371
  • 2
  • 33
  • 45
  • 1
    Great addition - using that field in CloudWatch logs no longer requires scripts to store global variables (initialized during an instance start) to recognize a cold start from a handler function. – Jochem Schulenklopper Sep 19 '20 at 17:06
  • Init Duration seems to be more about time to initialize lambda, but does not include time spent by program initialization, until request if started to be really processed. This is visible from LOGs, where for example `Init Duration: 1010.66 ms` and `INFO lambdainternal.AWSLambda - Started AWSLambda in 28.575 seconds (JVM running for 30.442)` (Spring Boot lambda) – Radouxca Jun 06 '23 at 06:27
12

If you're looking at CloudWatch logs, each LogGroup for your Lambda function represents a separate container and therefore the first invocation for that LogGroup is your cold start.

Noel Llevares
  • 15,018
  • 3
  • 57
  • 81
  • 1
    This statement is very interesting and might be useful. Would you please point me to the documentation where it is written so? – olpa Nov 02 '17 at 06:26
  • 3
    @olpa I asked the same question to Yan Cui [here](https://medium.com/@dashmug/thanks-for-responding-ce41bafc9e88) and I got this [response](https://medium.com/@theburningmonk/whether-or-not-invocations-overlap-in-the-same-container-is-a-different-question-to-whether-api-e8f37d712340). It seems like it is undocumented but confirmed by someone from Amazon. I can confirm it though from experience that logging something during a cold start will be seen at the beginning of the CloudWatch LogGroup. – Noel Llevares Nov 02 '17 at 09:53
  • Thanks, I think my experience and intuition confirm this way of working too. – olpa Nov 02 '17 at 11:17
  • I wrote some test code to check this (used `let coldStart = true` outside Lambda handler function, and `coldStart = false` inside function) and can confirm that a cold start always starts a new LogGroup in CloudWatch. – RichVel Jan 25 '18 at 08:29
  • @RichVel Thanks for confirming that. – Noel Llevares Jan 25 '18 at 12:39