agent timed out waiting for the CRM dashboard to render

TL;DR

CRM dashboards render in layers: shell, widgets, then data, often with long-polling that keeps the network busy forever. An agent waiting for full load or network idle waits for a condition that never occurs. Wait instead for the specific account data element, treat persistent spinners past a budget as a retryable failure, and capture a screenshot at timeout so the next failure is diagnosable.

agent timed out waiting for the CRM dashboard to render

Use this when

• The agent times out on dashboard pages that humans use fine
• Timeouts vary run to run on the same page
• Network-idle or load waits are the current strategy

Not for this skill when

• The CRM is slow for everyone due to an org-wide performance issue
• The agent's session lands on a login or error page instead

Steps

1. Record a trace of one failing load: which elements appear and when, and what never settles. Verify: the page's real readiness pattern is documented
2. Define readiness as the target data element populated, plus a hard overall budget. Verify: the new wait condition is precise and bounded
3. Implement the wait with a retry on a fresh page after budget expiry, screenshotting before retry. Verify: a hung page now retries once with evidence captured
4. Reduce page weight where possible: direct deep links to the account view instead of dashboard navigation. Verify: the agent skips the heaviest pages entirely
5. Track render-wait durations per run and alert on upward drift. Verify: CRM slowdowns are noticed as trends before they become timeouts

Variant phrasings

CRM dashboard render timeout agent

A related phrasing for the same underlying problem.

waiting for network idle never settles

A related phrasing for the same underlying problem.

browser agent slow CRM pages

A related phrasing for the same underlying problem.

Compatibility: Compatibility: Playwright or Selenium against CRM dashboards (Salesforce Lightning, HubSpot), current versions.

Why it happens

Modern app shells are never finished loading in the classical sense, so load-based waits are a category error. Readiness is a property of the element you came for. Deep links and element waits together cut both the wait and its variance.

Edge cases / pitfalls

• Lightning-style frameworks keep background polling alive indefinitely. Never use network idle there.
• A screenshot at timeout distinguishes slow page, login wall, and error page instantly. Always capture one.
• If deep links require permissions the agent lacks, fix the permission rather than scripting around the navigation every run.

Provenance

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