This is also affecting HW test not running for canary builds 
e.g.
https://uberchromegw.corp.google.com/i/chromeos/builders/daisy_spring-release/builds/1345/steps/HWTest%20%5Bbvt-inline%5D/logs/stdio
https://uberchromegw.corp.google.com/i/chromeos/builders/banjo-release/builds/10/steps/Signing/logs/stdio
https://uberchromegw.corp.google.com/i/chromeos/builders/glimmer-release/builds/291/steps/Paygen/logs/stdio

Actually c#1 issues seem to be related to 610536

The root causes is actually that SyncChrome is taking much longer than normal. We saw this once last week.

From:
https://uberchromegw.corp.google.com/i/chromeos/builders/x86-alex-chrome-pfq/builds/551/steps/Report/logs/stdio

SyncChrome:
  start:    0:25:26 median 0:13:35 mean 0:14:19 min 0:11:41 max 0:25:26
  duration: 0:51:02 median 0:05:52 mean 0:08:38 min 0:05:03 max 0:51:02
  finish:   1:16:28 median 0:19:38 mean 0:22:58 min 0:16:44 max 1:16:28

The SimpleChromeWorkflow has a mean duration of 1:08:21 and was killed after only 45 minutes.

Part of the problem was that this builder started late.

I filed  issue 611139  to track the PFQ master being too aggressive about killing slaves.

We should investigate the failures in comment #1, but we may also want to be better about identifying the cause of timeouts. SimpleChromeWorkflow runs last on the actual builder (as opposed to any DUT), so is often blamed for slow builders when the root cause is something else.

Per comment #2, see also:  issue 610536 

We can close this but we should decide whether or not we want to file another issue to better identify root causes of timeouts first.

Will close this one. Feel free to open another one to identify the root cause.