platform.start

What it is

platform.start is the smallest of the platform records and the one everything else depends on. Two fields: which request this is, and which version of the function ran it. That is all it needs to carry, because its job is to open a scope rather than to report anything.

The requestId is the important half. A CloudWatch log group receives lines from every concurrent execution of a function, interleaved in the order they happened to arrive, with no grouping of any kind. The only thing distinguishing one execution's output from another's is that identifier — stamped on this record, on the matching platform.runtimeDone and platform.report, and on every line the function logs in between. Reassembling an invocation means collecting everything that shares it.

The excerpt on this page shows why that matters more than it sounds. Two invocations start within 150 milliseconds of each other, and their output alternates: a start, a line, another start, another line, a result belonging to the first, a completion belonging to the second. Read top to bottom it is nonsense. Read by request ID it is two perfectly ordinary requests. Nothing is wrong with the logs; they are simply stored in arrival order rather than in the order that means anything.

The version field is quieter but occasionally decisive. When a function is invoked through an alias, this reports the version the alias actually resolved to — so during a weighted deployment, where an alias splits traffic between two versions, this field is what tells you which code handled a given request. If failures cluster on one version and not the other, that is visible here and essentially nowhere else in the log.

What it looks like in your logs

With Advanced Logging Controls set to JSON, this record arrives as an envelope. Here it is raw, and then read the way the text format would have shown it.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

What the record contains

Every field Lambda writes in this record, and what each one is telling you.

When it appears

Once per invocation, as the first record for that request ID. On a cold start it follows platform.initStart and the initialisation is already complete by the time it appears — which is why init time is reported later, on platform.report, rather than here.

It is the boundary between initialisation and execution. Anything logged before it belongs to container startup and is not attributable to any single request; everything after it, until the matching platform.runtimeDone, belongs to this invocation.

With multiple executions running concurrently in one log group, several platform.start records appear interleaved with each other's output. That interleaving is the whole problem this record exists to solve: the requestId is what lets a reader reassemble which lines belong together.

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Lambda Telemetry API Event schema reference
• AWS Lambda Developer Guide — Configuring advanced logging controls