Short answer: - successfulJobsHistoryLimit / failedJobsHistoryLimit apply to CronJobs; Prefect runs each flow run as a one-off Kubernetes Job, not a CronJob. So those two fields are not used by Prefect. - The right knob is Job.spec.ttlSecondsAfterFinished. In Prefect 3.x you set this via the Kubernetes work pool variable finished_job_ttl. Set it once at the work pool level (global for that pool) and optionally override per-deployment. - The Prefect Helm chart doesn’t expose this; preferred is to configure it on the work pool (UI or CLI / base job template), not via Helm. Where to set it 1) Globally for a pool (recommended) - Prefect Cloud UI: Work Pools → your Kubernetes pool → Variables → “Finished Job TTL” (seconds). - Or via a custom base job template when creating/updating the pool: Get the default template:

prefect work-pool get-default-base-job-template --type kubernetes > base.json

Edit base.json to ensure the template includes (it does by default):

"job_configuration": {
  "job_manifest": {
    "spec": {
      "ttlSecondsAfterFinished": "{{ finished_job_ttl }}",
      ...
    }
  }
},
"variables": {
  ...
  "finished_job_ttl": {
    "title": "Finished Job TTL",
    "type": "integer",
    "default": 3600
  }
}

Apply it to a pool (creates or updates):

prefect work-pool create "my-k8s-pool" --type kubernetes --base-job-template ./base.json --overwrite

2) Per-deployment override In your prefect.yaml:

deployments:
- name: my-deployment
  entrypoint: path/to/flow.py:flow_fn
  work_pool:
    name: my-k8s-pool
    job_variables:
      finished_job_ttl: 3600

Notes and preferred GC strategy - Prefect uses batch/v1 Job resources for each run; CronJob history limits are not relevant here. - TTL-based cleanup (ttlSecondsAfterFinished via finished_job_ttl) is the preferred and simplest strategy. Typical values are 60–3600s depending on how long you want to keep Jobs around for debugging. - Helm: There isn’t a Helm value to set this globally. Use work pool variables (UI or base job template) as the global lever. You can automate this by checking your base job template into source control and applying it with the CLI as part of your environment bootstrap. - If you need cluster-wide cleanup, Kubernetes also supports a controller-level terminated pod GC and you could add your own admission webhook defaults—but for Prefect users, finished_job_ttl on the pool/deployment is the intended approach. Docs and references - How to run flows on Kubernetes: How to run flows on Kubernetes - Customize base job templates: Customize base job templates - Customize job variables in deployments: Customize job variables - prefect.yaml reference: prefect.yaml - Kubernetes worker API (variables like finished_job_ttl): Kubernetes worker API If you share how you’re creating your work pool (UI vs CLI/automation), I can give you a one-liner or template you can drop into your process.