Error: Runtime exited with error: signal: killed

What it means

Every Lambda invocation runs inside a Linux container with a hard memory limit set by your MemorySize configuration. That limit is enforced by the kernel's control groups, not by the runtime, and the kernel's enforcement mechanism is blunt: when a process in the cgroup tries to allocate past the limit, the OOM killer sends it SIGKILL.

SIGKILL is the one signal a process cannot catch, block, or handle. There is no shutdown hook, no finally block, no exception handler, and no opportunity to flush a log line. The process is removed from the scheduler between one instruction and the next. This is exactly why the failure is so disorienting the first time you meet it — every other Lambda failure leaves a stack trace pointing at a line of your code, and this one leaves a gap where your logs used to be.

What Lambda writes afterwards, Runtime exited with error: signal: killed, is the supervisor's observation, not your function's report. The supervisor noticed the runtime process was gone and recorded how it went. It has no idea what your code was doing at the time, which is why the message contains nothing useful about your program.

The useful information is in two places instead. The REPORT line's Max Memory Used equals Memory Size exactly — the allocation was still climbing when the process died, so the high-water mark is the ceiling. And your own last log line marks how far the work got before the allocation that crossed the line. Those two facts together tell you both that it was memory and where the memory went, which is why reading them next to each other — rather than hunting for a REPORT line among thousands, several screens away from the log lines it belongs to — is the difference between a two-minute diagnosis and an afternoon.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

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.

How to confirm it from the logs

The decisive evidence is on the REPORT line, not the error line. Compare Max Memory Used against Memory Size: for an OOM kill they are equal, because the process was killed the instant it crossed the ceiling. That equality is the confirmation — the signal: killed text alone can also mean the sandbox was reclaimed for another reason.

The second tell is the absence of anything. No stack trace, no [ERROR] line, no exception name. Your own logs simply stop, mid-work, at whatever the last thing you wrote was. If you have a stack trace, this is not an OOM kill.

Causes, most likely first

Fixes

yaml# AWS SAM
Resources:
  ReportFunction:
    Type: AWS::Serverless::Function
    Properties:
      MemorySize: 1024   # was 512; observed peak was 512/512

jsimport { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { createInterface } from "node:readline";

const s3 = new S3Client({});

export const handler = async (event) => {
  const object = await s3.send(new GetObjectCommand({
    Bucket: event.bucket,
    Key: event.key
  }));

  // One line in memory at a time, not the whole object.
  const lines = createInterface({ input: object.Body });
  let count = 0;
  for await (const line of lines) {
    await handleRow(JSON.parse(line));
    count += 1;
  }
  return { count };
};

js// Wrong: grows forever across every invocation this container serves.
const cache = new Map();

// Right: bounded, so a warm container has a memory ceiling of its own.
const MAX = 500;
const cache = new Map();
function remember(key, value) {
  if (cache.size >= MAX) cache.delete(cache.keys().next().value);
  cache.set(key, value);
}

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 — Configuring function memory
• AWS Lambda Developer Guide — Troubleshoot invocation issues