I've been conducting a rather extensive evaluation of Auth0 for a potential enterprise deployment, focusing specifically on the user journey and reliability of core, non-negotiable flows. While the platform's dashboard and rule/action extensibility are impressive from an analytical standpoint, I've encountered a concerning pattern during my stress testing of the password reset functionality.
Over the past three weeks, I have methodically triggered the password reset flow from various tenant regions (US, EU) and for a mix of test users. The issue is intermittent but significant: approximately 15-20% of the time, the password reset email simply fails to arrive. There is no discernible pattern regarding user email domain (Gmail, Outlook, corporate). The Auth0 logs show the "Post Change Password" event and the "Send Email" event with a success status, yet the email never lands in the inbox or spam folder. This is not a configuration issue with my email provider, as other transactional emails from Auth0 (like verification codes) arrive with near-perfect reliability.
To rule out environmental factors, I performed a side-by-side comparison with a simple SMTP-triggered reset flow built in-house, which exhibited no such dropouts. This points to a potential inconsistency within Auth0's email delivery service or its internal queueing mechanism for this specific flow type.
Has anyone else in the community undertaken a similar deep dive and observed this behavior? I'm particularly interested in:
* Whether this is isolated to certain tenant regions or a broader infrastructure issue.
* Any correlation with specific "Password Reset" email template customizations (though I've tested both default and lightly modified versions).
* If there are known latency thresholds after which the email might *eventually* arrive (my observation window has been 60 minutes).
* Whether using a custom email provider (like SendGrid or SES) via the Auth0 dashboard mitigates the issue entirely.
The business intelligence implications of a core authentication flow with an apparent 80-85% success rate are severe, as it directly impacts user support volume and erodes trust. I'm currently compiling metrics and logs to present a formal case, but community data would be invaluable for comparison.
compare fearlessly
That's a troubling pattern, especially with the logs indicating success. I've seen similar behavior in enterprise integrations, and it often points to a subtle race condition or timeout between Auth0's internal email service and the audit/logging pipeline.
A hypothesis: the "Send Email" log event might fire upon successful handoff to their internal mail queue, not upon actual SMTP delivery. If their queue processor has intermittent failures or downstream throttling with providers, the log would still be green. Your side-by-side test with direct SMTP is the right move; it isolates the variable.
Have you checked if the missing emails correlate with any specific time of day or tenant activity spikes? You might be hitting an obscure, partially-failed state in their multi-region email routing infrastructure.
infrastructure is code
That's a really thorough test you've done. 15-20% failure on a core flow is way too high for enterprise, even if it's intermittent. It's scary that the logs show success.
When you did your side-by-side test with the simple SMTP flow, did you see a 0% failure rate? If so, that really isolates it to their service. Have you opened a support ticket with them yet? I wonder if they'd acknowledge a known issue with their email queue.