diff --git a/Flake-bisect.md b/Flake-bisect.md
index 168d730..139437f 100644
--- a/Flake-bisect.md
+++ b/Flake-bisect.md
@@ -43,7 +43,7 @@
 If a failing run times out, while a pass is running very fast, it is useful to tweak the timeout_sec parameter, so that bisection is not delayed waiting for the hanging runs to time out. E.g. if the pass is usually reached in <1 second, set the timeout to something small, e.g. 5 seconds.
 ### Getting more confidence on a suspect
 In some runs, confidence is very low. E.g. calibration is satisfied if four flakes are seen in one run. During bisection, every run with one or more flakes is counted as bad. In such cases it might be useful to restart the bisect job setting to_revision to the culprit and using a higher number of repetitions or total timeout than the original job and confirm that the same conclusion is reached again.
-### Working around known timeout issues in windows ([crbug.com/v8/8170](https://crbug.com/v8/8170))
+### Working around known timeout issues on windows ([crbug.com/v8/8170](https://crbug.com/v8/8170))
 Sometimes the overall timeout option doesn't work on windows. In this case it's best to estimate a fitting number of repetitions and set total_timeout_sec to 0.
 ### Test behavior depending on random seed
 Rarely, a code path is only triggered with a particular random seed. In this case it might be beneficial to fix it using extra_args, e.g. `"extra_args": ["--random-seed=123"]`. Otherwise, the stress runner will use different random seeds throughout. Note though that a particular random seed might reproduce a problem in one revision, but not in another.
\ No newline at end of file