K6 browser test causing K6 POD crash (OOM killed)

We are running a browser base UI test with the following config:

 ui: {
            executor: 'shared-iterations',
            vus: 3,
            iterations: 3,
            options: {
                browser: {
                    type: 'chromium',
                },
            },
        }

It is loading a lot of records on the page, and checking it locally on a Mac, chrome shows that only 181 MB is used by the tab. The K6 POD instance is failing and is showing OOM killed even though it has a pretty hefty resource allocation

      resources:
        limits:
          cpu: '8'
          memory: 8Gi
        requests:
          cpu: '4'
          memory: 4Gi

The error I am seeing is:

time="2025-06-18T15:36:16Z" level=warning msg="Unexpected DevTools server error: Target has crashed" category="ExecutionContext:eval" elapsed="644 ms" source=browser
time="2025-06-18T15:36:16Z" level=warning msg="failed to hide page: evaluating JS: Target has crashed" category="Page:Close" elapsed="0 ms" source=browser
time="2025-06-18T15:36:16Z" level=error msg="Uncaught (in promise) internal error while removing binding from page: Target has crashed" executor=ramping-vus scenario=post_scenario
time="2025-06-18T15:36:45Z" level=warning msg="Unexpected DevTools server error: context deadline exceeded" category="ExecutionContext:eval" elapsed="0 ms" source=browser
time="2025-06-18T15:36:45Z" level=warning msg="failed to hide page: evaluating JS: context deadline exceeded" category="Page:Close" elapsed="0 ms" source=browser
time="2025-06-18T15:36:45Z" level=error msg="Error occurred:\nName: undefined\nMessage: undefined\nStack: undefined\nDetails: {}" source=console

Could someone tell me what we can optimize to fix this? We would like to run this on a single pod, i.e. parallelism set to 1.

discardResponseBodies can help reduce memory usage in k6 browser tests by preventing the storage of HTTP response bodies. However, it’s essential to consider the additional memory consumption introduced by the browser instance.

I try and make sure for my tests that I have 5 cores and 4 Gi of memory per browser VU

Thanks alexcentorbi07. I will try with this option set and update.

Why 5 cores and 4 Gi of memory per browser VU? Based on the info here Running large tests | Grafana k6 documentation, 1000VUs should take between 1-5GB memory. Our tests typically expect at least 1000 VUs. With the estimate that you provided, I believe it will be pretty expensive even to get a single run, unless I am missing something here.

Update: using discardResponseBodies helped resolve the issue with the POD crash.

I believe those recommendations are based off of k6 api tests not the browser tests. When running the browser test they just require a lot more resources

1 Like