Time Limit Exceeded (TLE) error when switching judges for a small coding‑practice app

Goal

Migrate a small application that relies on LeetCode‑style judging to a new container‑based judge service while maintaining zero downtime, ensuring that submissions that previously passed continue to receive the same verdict.

The exact wall‑clock timeout that triggers a Time Limit Exceeded (TLE) verdict is not published and varies by language and problem, causing the condition to be nondeterministic for solutions that run close to the limit.

• How can the migration verify that the new judge’s TLE threshold matches the original LeetCode behavior without causing false positives?
• What monitoring strategy can detect a shift in the timeout value during the cutover?
• Is it acceptable to introduce a small safety margin in the submission time limit, and if so, how should it be calibrated?