## TL;DR
Dashboards make many API calls on load, so the default timeout is often too short. Raise it for the dashboard page, wait for the seat-count selector specifically, retry once, and fall back to the vendor's export or API if it keeps timing out.

```text
playwright timed out when agent tried to scrape seat usage dashboard, scrape failed
```

## Use this when
- Playwright times out on a seat usage dashboard.
- The dashboard loads for humans but slowly.
- The default 30-second timeout fires.

## Not for this skill when
- The page blocks automation. Use the sanctioned path.
- The selector is wrong. Fix the selector.
- Login fails first. Fix login.

## Steps
1. Set a longer default timeout for this page. Verify: the timeout exceeds the dashboard's real load time.
2. Wait for the seat-count selector specifically, not page load. Verify: the wait targets the data.
3. Retry once on timeout. Verify: the retry is a fresh attempt.
4. If it still times out, fall back to the vendor's export or API. Verify: the fallback returns data.
5. Confirm the seat data. Verify: the numbers are sane.

## Variant phrasings
### playwright timeout
The short phrasing.
### dashboard scrape failed
The action-first search.
### seat usage dashboard
The page-first phrasing.

Compatibility: Playwright automation on SaaS dashboards.

## Why it happens
Dashboards fan out to many backend calls on load. The default timeout assumes a simple page; dashboards are not simple pages.

## Edge cases / pitfalls
- The selector changing between loads; prefer text-based or role-based selectors.
- The dashboard paginating the counts; the first page is not the total.
- Waiting on page load instead of the element; the load event may never fire cleanly.
- The retry needing a fresh page, not a re-wait on the timed-out one.

## Provenance

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