Question
Which severity threshold should trigger email alerts in DRF exception handling?
Rahul Atlas
0 reputation · 25 May 2026, 11:43 UTC
79.7K views
Loading…
0 reputation · 25 May 2026, 11:43 UTC
In a Django‑REST‑Framework (DRF) project, the default exception_handler can be overridden to funnel all unhandled exceptions into a custom logger. The standard Django logging framework offers an EmailHandler that can be wired to send alerts when a log record reaches a certain level. By combining a custom exception handler with a logging filter that excludes non‑critical status codes (e.g., 404, 403), developers can reduce notification noise, but the decision of what constitutes a “critical” exception remains unresolved.
How should the severity of an exception be quantified so that only truly problematic errors trigger an email, while harmless failures are logged silently? The current approach typically relies on HTTP status codes or exception types, yet neither method guarantees optimal alert coverage or noise suppression.
Configure the email alert threshold to logging.ERROR (or any level ≥ ERROR).
django
djangorestAdminEmailHandler only emits emails for log records with level ERROR or higher.django.request logger at ERROR level.If you override exception_handler and call logger.error(exc, ...) (or logger.exception), the record reaches the AdminEmailHandler and triggers an email. Using a lower level (e.g., WARNING) would cause many routine requests (404, 403) to generate email, increasing noise.
LOGGING:LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
},
},
'loggers': {
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': False,
},
},
}ADMINS (or MANAGERS) is set with the email addresses that should receive alerts.logger.error (or logger.exception) for exceptions you want emailed.What logging level does your custom exception handler use for unhandled exceptions? If it logs at a level other than ERROR, adjust the handler’s level accordingly or change the handler’s call to error.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 25 May 2026, 18:32 UTC
The ERROR-level recommendation is sound, but it misses a scaling problem: a single bug under real traffic can generate thousands of AdminEmailHandler emails in minutes, since Django sends one email per log record with no built-in rate limiting. For anything beyond low-traffic APIs, the threshold question is only half the design.
Two practical mitigations:
logging.Filter in front of the mail handler that deduplicates by exception class plus request path within a time window, so repeat occurrences of the same failure produce one email.exc_info and request metadata on the suppressed WARNING-level records for 4xx responses — filtering purely on status code can hide abuse patterns (e.g., a burst of 403s) that are worth investigating even if they shouldn't page anyone.For validation, the empirical check works well: run the candidate rules for a week and confirm every email corresponded to something requiring human action. If your volume is high, an error-tracking tool with built-in grouping is usually a better fit than raw email.