k6 teardown rollback gap after schema changes under forced termination

Answer the question first

Does k6 guarantee teardown execution after a graceful stop? – Yes. In all supported releases that include the teardown() hook (v0.45+ and back to v0.28), a SIGINT or SIGTERM causes k6 to finish the current iteration, wait for all VUs to finish, then invoke teardown() before exiting.

What happens when the process is killed abruptly? – A SIGKILL (or similar non‑interceptable signal) terminates the process immediately. k6 never receives the signal, so teardown() is not executed. This has been consistent since reliable signal handling was added.

How should schema rollback be structured when teardown may not run? – Implement the rollback as an independent, idempotent script that runs after the k6 process exits, regardless of exit status. Wrap the k6 invocation in a supervisor that waits for the process to finish and then triggers the cleanup.

Why teardown is not a safety net for forced termination

• k6’s signal handling is only for SIGINT/SIGTERM; SIGKILL is uncatchable.
• Older releases (
• Even on graceful stops, teardown runs after all VUs finish, so a long‑running VU could delay cleanup.

Recommended pattern for reliable rollback

1. Prepare an idempotent rollback script – e.g., cleanup.sh that drops temporary tables or restores a baseline snapshot. It should be safe to run multiple times and should check for the existence of the objects before attempting to drop them.
2. Wrap the k6 run in a shell wrapper that captures the exit status and triggers the cleanup.

   #!/usr/bin/env bash
   set -e
   
   # Run k6 and capture its exit code
   k6 run test.js
   EXIT_CODE=$?
   
   # Always run cleanup, regardless of exit code
   ./cleanup.sh
   
   # Exit with the original k6 status
   exit $EXIT_CODE
   

3. Use trap for graceful signals – The wrapper can also trap SIGINT/SIGTERM to allow early cleanup if the user hits Ctrl‑C while k6 is still running.

   trap 'echo "Interrupted"; kill -s SIGTERM $k6_pid' INT TERM
   

4. Verify the workflow – Create a test where teardown() writes to a file. Run with SIGINT, confirm the file is updated; run with SIGKILL, confirm the file is unchanged; finally run the wrapper, confirm cleanup.sh executes in both cases.

Verification steps you can run locally

• Write a simple k6 script:

  import http from "k6/http";
  export default function () { http.get("http://example.com"); }
  export function teardown() { require("fs").writeFileSync("teardown.log", "done"); }
  

• Run with k6 run script.js, press Ctrl‑C after 5 s, then check teardown.log exists.
• Repeat, but kill the process with kill -9 $(pgrep k6) and verify teardown.log is missing.
• Use the wrapper script above and confirm that cleanup.sh runs in both scenarios.

Final recommendation

Rely on teardown() only for non‑destructive or idempotent cleanup that can tolerate occasional omission. For destructive schema changes, always use an external, idempotent rollback that is invoked by a wrapper or orchestration tool after the k6 process exits. This guarantees cleanup even if the test is killed abruptly.

If you need to know the exact k6 version you are running, run k6 version. For older releases (