Error Classification

Every captured failure gets an ErrorClassification — a label that tells the fixer which fix strategy to apply and tells you, at a glance, what kind of break happened.

Classifications

Classification	Category	Meaning
SELECTOR_NOT_FOUND	action	Selector missing or changed — the classic “site redesigned” break
SELECTOR_TIMEOUT	action	Element exists but the action timed out
NAVIGATION_FAILED	network	Page navigation failed
NETWORK_TIMEOUT	network	Request or response timed out
NETWORK_ERROR	network	DNS, SSL, or connection failure
CREDENTIALS_INVALID	data	Login failed, auth rejected
DATA_VALIDATION	data	Unexpected data shape or value
BROWSER_CRASH	crash	Browser process died
BROWSER_CLOSED	crash	The page or browser was intentionally closed, often by an app-level error handler
PERMISSION_DENIED	crash	Clipboard, file access, or similar permission failure
RUNTIME_ERROR	programmatic	TypeError, ReferenceError — a bug in the script itself
UNKNOWN	—	Nothing matched

How classification works

Classification is two-tier:

1. Observer state first. The PageObserver knows things the error message doesn’t — whether the network was failing, whether the browser process died, what the last successful action was. If the observer’s state explains the failure, that wins.
2. Message heuristics second. Otherwise, the error message and type are matched against known Playwright failure patterns.

Why it matters

• Fix guidance. Each classification maps to specific instructions in the fixing agent’s prompt — a SELECTOR_NOT_FOUND sends the agent hunting through the captured DOM for the replacement element; a CREDENTIALS_INVALID tells it a code change probably won’t help, so it should triage instead.
• Deduplication. The classification is part of the error hash. See Fix Lifecycle.
• Triage at a glance. The dashboard and Slack messages lead with the classification, so you know whether a failure is fixable-by-code before reading anything else.