This is happening on several different try bots, and is affecting the ability to get CLs through the commit queue :(

It looks like the archive step is working, but *very* slowly. I've been following the stdout stream on my job (https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/227061/steps/archive_webkit_tests_results/logs/stdio), so I can see that it is progressing, but it is taking a very long time. Previous runs (the ones reported as flakes here) appear to have just timed out.

This step generally takes ~7 minutes; these failed runs are taking >1h30 before failing the job.

Labs, can you see anything weird w.r.t bandwidth on these machines? One of the affected machines is vm334-m4 (looking at https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/227338/steps/archive_webkit_tests_results/logs/stdio)

Nothing we can do about it. We've hit max limit for NAT bandwidth that our current peering equipment can handle. 

There's a maintenance next Tuesday to move us to new equipment and double the pipe.

Detected 4 new flakes for test/step "archive_webkit_tests_results". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyJwsSBUZsYWtlIhxhcmNoaXZlX3dlYmtpdF90ZXN0c19yZXN1bHRzDA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).

This is labs issue

dba: Since we're past the Tuesday mentioned in comment 5, is this (likely) Fixed?

Assigning to you to close if so, or else clarify the updated status of this.

I don't know if this particular problem is fixed, but our maintenance had to be rescheduled.

Bandwidth has now been officially doubled, so I'm going to close this.