You’re seeing a SIGKILL (-9) which usually means the container was OOM-killed. Since you’re on an ECS work pool with launch type EC2, the fix is to re-run the same deployment with higher `cpu`/`memory` job variables. For EC2, these apply at the container level. Fastest options - CLI (per-run override)

# If you know the deployment name:
prefect deployment run "YOUR_FLOW/YOUR_DEPLOYMENT" \
  --job-variable cpu=2048 \
  --job-variable memory=8192 \
  --watch

# Or, find the deployment id from the failed run, then:
prefect flow-run inspect <RUN_ID>
prefect deployment run --id <DEPLOYMENT_ID> \
  --job-variable cpu=2048 \
  --job-variable memory=8192

- UI (per-run override) - Open the deployment in the UI → Run → Custom Run - Add job variables:

cpu=2048

,

memory=8192

- Submit Notes for ECS EC2 -

cpu

is in CPU units (1024 ≈ 1 vCPU).

memory

is in MiB. - On EC2 launch type, Prefect sets these on the container definition; ensure your ECS container instances have enough free resources to place the task. Make it stick for future runs - If this run succeeds, bake the new defaults into the deployment or work pool so you don’t need to override every time. prefect.yaml (deployment-level defaults)

deployments:
- name: your-deployment
  entrypoint: path/to/flow.py:flow
  work_pool:
    name: your-ecs-pool
    job_variables:
      cpu: 2048
      memory: 8192

Or edit your ECS work pool defaults in the Prefect UI (Work Pools → your ECS pool → Edit defaults) and set `cpu`/`memory` there. Helpful docs - Override job variables (per deployment and per run) - ECS worker overview - ECS worker manual deployment guide If you want, paste the failed run’s deployment name (or RUN_ID) and the target resources you’d like, and I’ll give you an exact command.

Great goal — you don’t need to “redeploy” to do this. In Prefect 3.x the clean pattern is: - Detect the crash with an Automation - Automatically “Run deployment” again with higher `cpu`/`memory` job variables That re-queues the same deployment immediately with more capacity on ECS EC2. How to set it up in the UI 1) Go to Automations → New → Event-based 2) Trigger - Events:

prefect.flow-run.Crashed

- Match (optional but recommended): -

prefect.state-message

contains something like

status code: -9

or

SIGKILL

or

memory

- Match related → Role:

deployment

and select your deployment (or filter by tags/env) - For each:

prefect.resource.id

(ensures per-run evaluation) 3) Action: Run deployment - Select your deployment - Job variables (increase resources for rerun): - `cpu`: 2048 - `memory`: 8192 - Optionally add a small delay (e.g., 30–60s) with “Schedule after” to avoid immediate thrash Example Automation payload (REST API)

POST /api/automations/

{
  "name": "Auto-rerun on OOM with higher ECS EC2 resources",
  "description": "Rerun crashed flows (SIGKILL/OOM) with more CPU/memory",
  "enabled": true,
  "trigger": {
    "type": "event",
    "posture": "Reactive",
    "expect": ["prefect.flow-run.Crashed"],
    "threshold": 1,
    "match": {
      "prefect.resource.id": "prefect.flow-run.*",
      "prefect.state-message": "*status code: -9*"
    },
    "match_related": {
      "prefect.resource.role": "deployment",
      "prefect.resource.id": "prefect.deployment.<YOUR_DEPLOYMENT_ID>"
    },
    "for_each": ["prefect.resource.id"]
  },
  "actions": [
    {
      "type": "run-deployment",
      "source": "selected",
      "deployment_id": "<YOUR_DEPLOYMENT_ID>",
      "job_variables": {
        "cpu": 2048,
        "memory": 8192
      },
      "schedule_after": 30
    }
  ]
}

Notes for your ECS EC2 setup -

cpu

is in CPU units (1024 = 1 vCPU);

memory

is in MiB. On EC2 launch type, Prefect applies these at the container level. - Ensure your ECS container instance(s) have enough free capacity to place the larger task. - If you run dev/stage/prod on the same host, consider scoping the automation by deployment or tags so it only affects the intended environment. Optionally, escalate on repeated crashes - Create a second Automation that also listens for

Crashed

on the same deployment and runs with even larger `cpu`/`memory`. - Keep in mind there’s no built-in “max retries” counter in a single Automation; you’ll need separate automations/filters or manually clean up if you’re worried about runaway reruns. Docs - Automations: Concepts - Event triggers: Event triggers - Override job variables (per run via automations): Customize job variables - ECS worker (AWS): ECS worker overview If you share the deployment ID and your desired CPU/memory increments, I can draft the exact Automation JSON for you.