Footprint and scheduling

Every run records its own cost. Both attempts count when a check retries; the wall duration also includes the wait. Budgets warn without changing the suite’s pass/fail result.

budget:
  max_requests: 100
  max_duration_ms: 60000
  max_http_ms: 45000

Measurement	Meaning
Requests	Synchronous httpx calls and observed Playwright browser HTTP(S) requests, including failures and redirect hops
Bytes	httpx response-stream bytes consumed and available encoded browser response-body sizes, excluding headers
HTTP time	httpx send/read time and browser request lifetimes, summed across concurrent requests
Duration	Wall time of all attempts and retry/confirmation waits

The runner automatically observes Playwright browser contexts, including both Python APIs, persistent contexts, popups, frames, assets and fetch/XHR requests. It adds no target requests and does not read browser response bodies to measure them. Counts include observed third-party, cached and aborted requests; some may not reach the origin. Body sizes may be unavailable after failures or closure. Concurrent browser requests can make summed HTTP time exceed wall duration.

Async httpx, Playwright’s separate APIRequestContext, WebSocket frames and traffic not emitted as browser request events remain unmeasured. An unknown footprint after a killed run is not zero. HTTP time is an external latency/load indicator, not a measurement of target CPU. Older browser runs only counted httpx calls; review new measurements before comparing historical averages or changing budgets.

An over-budget run gets a UI warning, a stored explanation, a Prometheus gauge and a low-priority Pushover at most once per suite per day. Configure a wall budget that includes the 60-second wait for emergency suites; otherwise every emergency confirmation will exceed the default one-minute budget.

uv run --env-file .env talaia footprint
uv run --env-file .env talaia footprint --strict

The report combines recent measured requests with schedule frequency. TALAIA_MAX_REQ_PER_HOUR sets the warning threshold, default 600 per suite. This is a per-suite estimate, not a sum across all suites sharing a server.

Choose a light schedule

• Surface checks: every 15–30 minutes.
• Login/write and browser checks: every 30 minutes.
• Reviewed permanent-data flows: daily.
• Keep request timeouts bounded and ordinary retries at one.

Stagger suites of the same project. The maintained fleet allows at most two suite starts per minute across projects; execution can overlap because durations vary. Adding a suite must preserve that start budget or include an explicit scheduling change. Review footprint measurements after rollout rather than assuming staggering alone proves low production load.