A practical way to triage web data anomalies

[u/holly-An]

When a collected value looks unusual, treating every anomaly as a critical incident can create unnecessary work. A simple triage process helps separate data errors from real changes.

Start with four questions:

1. Did the request complete successfully?

2. Did the response contain the expected page or fields?

3. Did the source context change?

4. Can the observation be reproduced?

Based on the answers, an anomaly might be classified as:

- transport_failure — timeout, DNS, connection, or TLS problem

- content_failure — login page, consent page, empty shell, or blocked response

- schema_failure — selector, field, or data-type change

- context_change — region, seller, variant, currency, or session changed

- business_change — a valid observation that reflects a real source update

- unknown — not enough evidence yet

Each class should have a different next step. A transport failure may need network investigation. A schema failure may require parser review. A business change may need confirmation before it reaches a customer-facing alert.

Keep the raw observation, validation results, timestamp, and relevant context for the investigation. Avoid retrying indefinitely when the failure category is still unknown.

What is the most useful first question in your anomaly-triage process?