## TL;DR
Dashboard scraping times out when the agent waits for the page to be done rather than for the specific table it needs, and billing dashboards are heavy: lazy tables, spinners, and session checks. Wait on the cancellation table's rows explicitly, paginate by the table's own controls, and where the dashboard calls an internal API, read that endpoint with the session instead of the pixels.

```text
browser automation failed on the billing dashboard: agent timed out scraping cancellation data
```

## Use this when
- Scrapes hang or time out at inconsistent points
- The dashboard eventually loads fine for a human
- Longer fixed sleeps helped slightly but never reliably

## Not for this skill when
- The dashboard is down or the account's session is expired at scrape time
- Scraping this system is prohibited by policy or terms, making API access the only route

## Steps
1. Reproduce the scrape with tracing on and note exactly which wait expires and on what element. Verify: the failing wait and its target are identified
2. Replace fixed and page-level waits with explicit waits for the cancellation table and its row count stabilising. Verify: the scrape proceeds as soon as data is actually present
3. Inspect the dashboard's network calls for the endpoint serving cancellation data. Verify: an API path for the same data is confirmed or ruled out
4. Move the pull to that endpoint where permitted, keeping the browser path as fallback with the explicit waits. Verify: the pull completes within time on repeated runs
5. Add per-run evidence: rows scraped, duration, and a screenshot on failure only. Verify: future failures arrive with their own diagnostics

## Variant phrasings
### billing dashboard scrape timeout
A related phrasing for the same underlying problem.
### browser automation waiting on table
A related phrasing for the same underlying problem.
### scrape cancellation data reliably
A related phrasing for the same underlying problem.

Compatibility: Compatibility: Playwright or Selenium automation against billing admin dashboards, current versions.

## Why it happens
Pages are never loaded in the way fixed waits imagine; data arrives element by element. Explicit waits on the actual target align the agent with the page's real behaviour, and the dashboard's own data endpoint removes the browser from the loop entirely where access permits.

## Edge cases / pitfalls
- Session expiry mid-scrape looks like a timeout. Check for a login redirect in the failure screenshot before tuning waits.
- Heavy dashboards paginate lazily on scroll. Row-count stabilisation must include the scroll or pager interaction.
- Keep failure screenshots and traces access-controlled; billing pages contain customer financial data.

## Provenance

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