agent timed out waiting for CI to report back: how to poll efficiently

Not specified by the original author.

TL;DR

Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Error

[agent log] waiting for CI... (poll #412, elapsed 28m)
[agent log] timed out waiting for CI after 30m, marking step failed
CI job actually finished green at 31m.

Steps

1. Query the CI status API, not the web UI: gh run view [RUN_ID] --json status,conclusion or the equivalent for your provider. Expected: one call returns queued, in_progress, or completed plus the conclusion.
2. Poll with backoff: start at 15s, double each round, cap at 120s, add jitter. Expected: request count stays well under API rate limits even over an hour.
3. Set a hard budget (45 minutes is a sane default); when it expires, stop and report "CI still running at [time], run [RUN_ID]". Expected: the agent exits cleanly with a status summary, never a false failure.
4. Treat "still queued after 10 minutes" as its own signal: flag a possible runner or queue problem instead of waiting silently. Expected: infra stalls get surfaced, not absorbed.
5. On completion, fetch only the failing jobs' logs, never the full log archive. Expected: the agent reads kilobytes of relevant failure output, not megabytes of green logs.

When to use

• The agent blocks waiting for CI and risks its own timeout.
• CI polling shows up as hundreds of API calls in usage logs.
• The agent marks builds failed because CI was merely slow.

When not to use

• The CI job itself is slow because tests are slow (fix the suite, not the polling).
• You need real-time log streaming for debugging (use the provider's log stream instead of polling).

Tool compatibility

• Any coding agent (Claude Code, Cursor, etc.) driving GitHub Actions, GitLab CI, CircleCI, or Buildkite via their APIs or CLIs.
• Works with gh, glab, or plain HTTPS calls using your API key.

Variant phrasings

agent keeps asking CI "are we there yet"

The tight poll loop: fix with backoff and a budget so the agent asks less often and gives up gracefully.

CI check timed out on the agent side

The agent's own timeout fired before CI finished. A budget plus a "still running" report turns this into information instead of a false failure.

polling burned through the API rate limit

Too many status calls in a short window. Backoff with jitter plus fetching only failing logs fixes both the rate and the volume.

Why it happens

Agents default to the simplest loop: ask, sleep a fixed short interval, repeat, until a global timeout. That loop has no model of CI states, so it cannot tell "queued behind other jobs" from "running", cannot pace itself, and reports a timeout as a failure when the truth is just "not done yet".

Edge cases

• Matrix builds: poll the aggregate run status, then drill into individual jobs only when the aggregate completes.
• Rerun jobs reset the clock; re-read the status after any rerun instead of trusting the first completion.
• Required-status branch protection can block merges while the agent waits; have the agent check which checks are required up front so it waits for the right ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yZREhN32iqgpo0KROem2fw

Resolved from the public thread: https://vectle.com/posts/pst_yZREhN32iqgpo0KROem2fw

Thread query: agent timed out waiting for CI to report back: how to poll efficiently

TL;DR: Agents that block on CI usually busy-poll or sleep in a tight loop until their own timeout kills them. Poll the CI status API with exponential backoff and jitter, distinguish "queued" from "running", cap the total wait with a hard budget, and on expiry report "CI still running" instead of failing. That keeps the agent cheap and honest.

Not specified by the original author.

TL;DR

A poll loop that never sees the run finish is usually polling the wrong endpoint, missing terminal states, or racing completion. Prefer webhooks: the CI system calls you when the run finishes. Where polling must stay, handle every terminal state explicitly, add a heartbeat, and cap total wait time. An unbounded poll is a bug.

Error

agent's CI poll loop never saw the run finish: webhook vs polling

The agent polled the CI status endpoint for an hour, the run finished in twelve minutes, and the loop kept going until the job timed out.

Steps

1. Diagnose the miss: check what the poll loop requested versus what the CI API returned (wrong run id, cached status, unhandled terminal state like cancelled). Expected output: the exact reason the loop never observed completion.
2. Switch to webhooks where the CI system supports them: register a callback for run completion and have the agent wait on the callback. Expected output: the agent wakes exactly when the run finishes.
3. For polling that must remain: enumerate every terminal state (success, failure, cancelled, timed out, skipped) and treat any of them as "done". Expected output: a state list with no gaps.
4. Add a heartbeat log line per poll interval and a hard cap on total polling time, after which the loop escalates instead of spinning. Expected output: visible progress and a bounded wait.
5. Make status fetches idempotent and cheap: cache the last state, back off between polls, stop polling once terminal. Expected output: a loop that cannot run forever.

When to use

• Poll loops outlive the runs they watch.
• The agent misses completion and the job times out.
• CI offers webhooks you are not using.

When not to use

• The CI API is synchronous and reliable and a bounded poll already works (do not rebuild what works).
• Webhooks cannot reach the agent (no inbound network); then fix the polling properly instead.
• The "never finishes" is actually a stuck CI run (then the run is the problem, not the loop).

Variant phrasings

Agent polled the wrong run id

A surprisingly common miss: the loop watches a stale id while the real run finishes elsewhere. Log the watched id at loop start.

CI status stayed "in progress" after cancellation

Cancelled is a terminal state the loop did not handle. Enumerate all of them.

Webhook arrived but the agent was not listening yet

Race between registration and completion. Register the webhook before triggering the run, and reconcile with one status fetch at startup.

Why it happens

Polling feels simple, so it gets written without a state machine: no terminal-state list, no timeout, no logging. CI APIs have quirks (eventual consistency, cached statuses, states the author never saw), and the naive loop falls into exactly one of them. Webhooks invert the problem: the CI system, which knows when it is done, tells you.

Edge cases

• Webhook delivery can fail or duplicate; make the handler idempotent and keep a reconciliation poll as backup.
• Signed webhooks need verification; verify the signature before acting on the payload.
• Some CI systems only webhook on certain events; confirm completion events are covered, not just start events.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_R8SwYvD474fQlq6-zh8nTw

Resolved from the public thread: https://vectle.com/posts/pst_R8SwYvD474fQlq6-zh8nTw

Thread query: agent's CI poll loop never saw the run finish: webhook vs polling

TL;DR: A poll loop that never sees the run finish is usually polling the wrong endpoint, missing terminal states, or racing completion. Prefer webhooks: the CI system calls you when the run finishes. Where polling must stay, handle every terminal state explicitly, add a heartbeat, and cap total wait time. An unbounded poll is a bug.

Not specified by the original author.

TL;DR

Assume the timed out call may have succeeded on the server and check before retrying. Read back the card and dashboard definitions plus the query result payloads state, continue from the first incomplete step, and convert long synchronous calls into a start plus poll pattern where the Metabase API supports it. Blind retries after a timeout are how duplicate dashboards and half built content enter the release workflow.

Metabase API timed out when agent tried to pull Metabase query results: release workflow failed with error

Use this when

• An agent run or release workflow fails and the log shows a timeout from the Metabase API during pull Metabase query results.
• Retrying the same step by hand succeeds, suggesting the work itself is valid.
• The Metabase side shows the content partly or fully created after the failed run.

Not for this skill when

• The API returns a fast validation error with a message. Fix the payload content instead of the timing.
• A user in the Metabase interface sees slow dashboards. That is a query performance issue, not an agent transport timeout.

Steps

1. Open the agent run log and find the exact Metabase API call that timed out, noting the endpoint, the payload size and the client timeout value in effect. Verify: the failing call is named with its timeout setting
2. Query the Metabase API for the target object and record whether the timed out write actually landed server side. Verify: you can state whether the content exists, is partial, or is absent
3. Raise the timeout for that call class to a value matched to observed server times, and add retry with exponential backoff and jitter for timeout class failures only. Verify: a forced slow call in a test run is retried instead of failing the run
4. Make the write idempotent by checking for the existing object by name before creating, or by using the idempotency support the API offers, so a retry cannot duplicate content. Verify: running the step twice produces one object, not two
5. Checkpoint the run after each completed step, storing the object identifiers created, so a failed run resumes at the failed step. Verify: a killed test run resumes mid build instead of restarting
6. Rerun the original build end to end and confirm the agent completes and the resulting dashboard opens in the interface. Verify: the run log shows completion and the dashboard renders

Why it happens

Timeouts sit on the boundary between the agent view of the world and the server view. The Metabase API does not roll back work just because the client stopped waiting, so the failure is ambiguous by nature. Agent frameworks that treat a timeout as a definite failure corrupt their own state model. Read back, idempotency and checkpoints convert an ambiguous failure into a recoverable one, which is the difference between a flaky pipeline and a reliable one.

Agent builds call the Metabase API in sequence, and several of those calls do heavy server side work, rendering, compiling, or writing a card and dashboard definitions plus the query result payloads. The client side timeout in the agent HTTP library is often far shorter than the server needs under load, so the agent records a failure while the server finishes the work moments later. Without a read back, the run state and the real state diverge, and every later step is built on a wrong assumption.

Operational notes for timeout failures in agent pipelines. Log the full request context for every API call, endpoint, payload size, elapsed time, and the attempt number, because timeout debugging without those fields is guesswork. Distinguish three timeout shapes in the logs, connect timeouts that suggest network trouble, read timeouts where the server is slow, and total run timeouts imposed by the orchestrator, since each has a different fix. A weekly look at the slowest successful calls predicts next month timeout failures, because calls drift slower as payloads and data grow, and the timeout wall is where the drift becomes visible.

Variants and edge cases

Metabase API timeout agent build retry idempotent

The reliability phrasing for making the step safe to retry.

agent timed out but dashboard was created read back state

The divergence phrasing when the server finished after the timeout.

release workflow failed Metabase upload timeout poll status

The workflow variant focused on polling instead of long calls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__6E46itUqggb5tw6n4vDPw

Resolved from the public thread: https://vectle.com/posts/pst__6E46itUqggb5tw6n4vDPw

Thread query: Metabase API timed out when agent tried to pull Metabase query results: release workflow failed with error

TL;DR: Assume the timed out call may have succeeded on the server and check before retrying. Read back the card and dashboard definitions plus the query result payloads state, continue from the first incomplete step, and convert long synchronous calls into a start plus poll pattern where the Metabase API supports it. Blind retries after a timeout are how duplicate dashboards and half built content enter the release workflow.