(I'm filing this as a result of some of the failures I've seen while sheriffing today ...)

If a step times out due to timeout set via swarming, it's not all that obvious that that's what happened.

Example:

https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/37148

the actual red step simply says that 30 tests failed, but not why.

If you click through to the log, you can see a bunch of messages like:

C  119.806s Main  [TIMEOUT] CoreTest.Basic:
C  119.806s Main    Suite execution terminated, probably due to swarming timeout.
C  119.806s Main    Your test may not have run.

but that's not terribly definitive.

In other cases, e.g.:

https://build.chromium.org/p/chromium.android/builders/Android%20N5X%20Swarm%20Builder/builds/6192/steps/telemetry_perf_unittests%20on%20Android/logs/stdio

you might just get obscure errors from logcat.

If you click back up to the "trigger" step and click over to the task summary, however, you can see that we get "State: Execution timed out".

We should make that very clear as part of the step that actually is marked as red. There's too many hoops to jump through.

In particular, since the timeout is set in the build configuration (the //testing/buildbot files), and not passed in to the test runner (and hence in the command lines) it may not be obvious at all to most sheriffs what is going on.

Thoughts on how to make this better?