DRF validation errors: alert as client errors or system errors in Sentry, Prometheus, Datadog?

Short answer

Treat DRF validation failures as client errors by default. Page only when they deviate from an established baseline or come from trusted/internal sources, which suggests schema drift, an upstream dependency problem, abusive integration, or a bug in your own API. Otherwise increment a dashboard counter and do not page.

Confirmed behavior and assumptions

DRF's default exception handler converts ValidationError into a 400 response; serializer.is_valid() raises only when called with raise_exception=True. A handled 400 is not an unhandled exception, so Sentry may not see it unless your custom handler explicitly captures it. Sentry event level, Prometheus label names, and Datadog tag behavior depend on your SDK/agent versions; verify them in your environment.

Classification criteria

Route	Condition
Dashboard only	Sporadic 400s from public clients, expected malformed input, rate within baseline, low-impact endpoint.
Page or alert route	Sudden rate change per endpoint/client/schema version, 400s from trusted/internal clients, repeated same validation failure from one client, high-value endpoint, or errors coinciding with upstream dependency failures.

Consistent implementation

1. Create one custom DRF exception handler. In it, classify each ValidationError and set request.drf_validation_classification to client_error or system_error.
2. Send system_error validation failures to Sentry with level: error and tags http_status_code=400, drf_validation_error=true, drf_validation_classification=system_error. Keep client_error out of Sentry or as a non-paging warning; enforce this in before_send so the rule is not repeated per view.
3. Increment a Prometheus counter such as drf_validation_errors_total{view,status,error_code,classification,client} from the same handler or middleware. Alert on rate deviation from baseline, not on every 400. Keep throttle rejections in a separate counter.
4. In Datadog APM, set span tags drf.validation_error=true, drf.validation.classification, and http.status_code=400. Monitor the validation tag rate, not all http.status_code:400 traces.

Verification

1. Call an endpoint with invalid input using both is_valid() and is_valid(raise_exception=True); confirm whether a 400 response is returned or an exception is raised.
2. Trigger a validation error and inspect Sentry to confirm before_send applied the intended level and tags.
3. Query the custom Prometheus counter during known-good traffic and during malformed input to confirm labels and rate anomalies.
4. Check Datadog span details for a 400 response to confirm the custom validation tag is present and consistent across views.

Missing diagnostic detail: how are validation failures currently surfaced—returned 400 responses or raised exceptions—and do they reach Sentry? This changes whether you need a custom handler to capture them at all.