diff --git a/src/test/resources/test.properties b/src/test/resources/test.properties
index d725c6f..2da7559 100644
--- a/src/test/resources/test.properties
+++ b/src/test/resources/test.properties
@@ -20,3 +20,15 @@ app.assistant.provider-retry-max-delay-ms=2
 
 app.import.path=src/test/resources/workflow-editor-init
 app.import.enabled=true
+
+# The Spring test context (and its singleton ExecutionsService) is reused across the whole
+# suite. Each execution gets its own dedicated Executors.newFixedThreadPool that only gets
+# shut down on cache eviction (see ExecutionsService.evictIfNeeded/evictFinalStateByTtl) -
+# with the production default of 1000 and a 30-minute TTL, a full test run (hundreds of
+# executions, none older than 30 minutes) never evicts anything, so hundreds of finished-but-
+# not-shut-down thread pools stay alive simultaneously. That OS-level thread contention is the
+# most likely cause of the loop-container tests occasionally missing their polling deadline
+# under full-suite load (they pass reliably in isolation). Evicting aggressively in tests keeps
+# the live thread-pool count small throughout the run.
+app.executions.cache.max-size=50
+app.executions.cache.final-ttl-ms=2000