Actions job waited 779 seconds before starting: how to distinguish concurrency admission from runner or dispatch delays?

[lzwislam-collab]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner

Discussion Details

Hello GitHub Community,

I am investigating a 779-second delay between job creation and job start. I would appreciate guidance on distinguishing workflow concurrency admission, runner allocation, account limits, and internal dispatch using historical evidence.

The delay is confirmed, but its specific cause remains unknown.

Repository and affected job

• Repository: lzwislam-collab/doge-data-collector
• Run: 39466011279, attempt 1
• Job: 118777484003 — hourly-history
• Event: schedule
• Branch: main
• Head SHA: 423905b7efd539bca9f5eba7dc335127779dd9b4
• Requested runner label: ubuntu-24.04
• Assigned runner: GitHub Actions 1000011131
• Workflow at the exact run head
• Workflow concurrency group: okx-hourly-extreme-history
• cancel-in-progress: false

The repository was public during the investigated period.

UTC timeline

All times below are UTC on October 20, 2026.

Event	Time
Run created_at	17:25:56
Job created_at	17:25:56
Run API run_started_at	17:25:56
Job started_at	17:38:55
First runner log entry	17:38:56.453284
First saved market quote timestamp	17:39:40.367
Core publication verified by remote readback	17:40:20.998098
Job completed_at	17:47:50

The job creation-to-start interval was 779 seconds (12 minutes 59 seconds). The run-level run_started_at value does not identify when this job actually began executing.

The relevant target had a fixed deadline of 17:38:06.421389 UTC:

• The job started approximately 48.579 seconds after the deadline.
• The first saved quote was approximately 93.946 seconds after the deadline.

The run ultimately concluded as cancelled, although core publication and remote readback had already completed successfully. That later cancellation is separate from the pre-job delay being investigated here.

Same-concurrency-group comparison

We retrieved all 630 repository runs created between 04:00 and 18:30 UTC, across all pages, and identified 53 same-group candidates using the workflow configurations.

Within that inspected scope, no other same-group run record overlapped 17:25:56–17:38:55 UTC.

Two earlier candidates were:

Candidate	Job execution interval, UTC
Previous normal collector: run 39460975742 / job 118760042072	16:50:41–16:59:39
learned_shadow_live: run 39459027877 / job 118753316779	16:37:11–16:38:22

These records do not support the previous normal collector holding the concurrency group until 17:38:55.

However, the inspected run records are not a complete backend concurrency-lease history. They cannot rule out stale or unreported state.

Cross-group comparison

Nearby jobs using different concurrency groups also experienced creation-to-start delays:

Run / job	Concurrency group	Created → started, UTC	Delay
39467177428 / 118781484727	doge-data-collector	17:33:50 → 17:37:32	222 s
39467831884 / 118783758392	doge-policy-price-alignment	17:38:24 → 17:41:44	200 s
39467832198 / 118783759665	doge-readiness-${{ github.ref }}	17:38:24 → 17:41:34	190 s
39467831693 / 118783757440	evidence-readiness-${{ github.ref }}	17:38:24 → 17:41:22	178 s

The first comparison job requested ubuntu-latest; the other three requested ubuntu-24.04.

This pattern is consistent with a broader startup delay, but it does not prove that these jobs shared the same cause, or establish runner capacity as the cause.

What is confirmed

• The 779 seconds occurred after run/job creation and before job execution.
• The affected job was not executing sampling or publication code during that interval.
• The delay caused the job to start after the fixed target deadline.
• No overlapping same-group run was identified within the inspected scope.
• Nearby jobs in other concurrency groups also had startup delays.

What remains unknown

• How the 779 seconds divides between concurrency admission, account limits, runner allocation, and internal dispatch.
• Whether stale or unreported concurrency state contributed.
• Whether runner capacity or a service-side issue contributed.
• Whether an additional schedule-delivery delay occurred before run creation. That would be a separate interval.

Questions

1. Is there a documented historical API, UI field, or diagnostic log that separates concurrency waiting from runner allocation and dispatch waiting?
2. Can repository-visible evidence identify the blocking run or concurrency-lease acquisition/release times?
3. How can account/organization concurrency-limit waiting be distinguished from runner-capacity waiting?
4. If only GitHub can establish the cause, which backend timestamps and reason codes should be requested?
5. Is there an evidence-based mitigation that preserves the existing concurrency protection and normal collector behavior?

GitHub Support ticket #4884494 was closed because this account has self-service support options. The response did not provide a technical diagnosis or backend timestamps.

I am seeking analysis of existing records first. I am not proposing to disable concurrency protection, rerun historical jobs, or change the normal collector based on an unproven cause.

Our separate five-second mean criterion for full Apps Script main executions remains unchanged. The 779-second Actions pre-job interval is a different measurement and is not being used to redefine that criterion.

[TM-threemavithana]

I checked the public job timestamps and compared the affected run against a sample of 59 jobs from the same workflow. A few things stood out.

The 779-second delay is a clear outlier. In that sample, 58 jobs started within 1–3 seconds of creation (median 2 seconds).

For [run #500](https://github.com/lzwislam-collab/doge-data-collector/actions/runs/39466011279), the job was created at 17:25:56 UTC and started at 17:38:55 UTC. That confirms the 779-second pre-start interval, but doesn't tell us which internal stage caused it.

The reconstructed public repository history showed no other executing jobs when run #500 was created. The previous visible run sharing its concurrency group had finished around 16:59:43, over 26 minutes earlier. This makes an ordinary overlapping-run blockage less likely, though it doesn't rule out internal concurrency state or account-level activity in inaccessible repositories.

Another interesting comparison is [run 39467177428](https://github.com/lzwislam-collab/doge-data-collector/actions/runs/39467177428). Its job was created later (17:33:51) but started earlier (17:37:32). However, it requested ubuntu-latest, while the affected job requested ubuntu-24.04, and they used different concurrency groups. So the execution order alone doesn't establish a concurrency issue.

Several other ubuntu-24.04 jobs also experienced 178–200-second pre-start delays. That indicates the longer waits weren't isolated to run #500, but doesn't prove runner provisioning was responsible.

The main limitation is observability: I couldn't find a documented public API that separates concurrency admission, runner assignment, and dispatch into individual historical timestamps.

For a definitive diagnosis, I'd ask GitHub Support to investigate job 118777484003, including its concurrency admission state, runner-allocation timeline, and internal scheduling decisions.

I wouldn't change the existing concurrency protection based on the available evidence alone.