Getting locked out shouldn't mean starting over
We shipped a self-serve password reset flow so users who forget their credentials can get back into their accounts without waiting on support.
Every product team eventually confronts the same uncomfortable truth: a non-trivial percentage of your users will forget their password. Not because they're careless, but because passwords are a fundamentally hostile UX pattern layered on top of human memory. The question isn't whether it happens — it's what happens next.
Until now, our answer was "email support." That worked when we were smaller. It stopped working the moment recovery requests started outpacing the rest of our inbound queue. So we built a proper self-serve reset flow. Reset a Forgotten Password
Why we prioritized this
Password recovery is the kind of feature that's invisible when it works and catastrophic when it doesn't. A locked-out user is a user who can't do anything else in your product — they can't renew, can't invite teammates, can't file a bug. Every minute between "I forgot my password" and "I'm back in" is a minute of pure friction, and often the moment where a wavering user decides the whole thing isn't worth it.
We also wanted to get support out of the loop. Human-in-the-loop password resets are slow for the user and expensive for us, and they're a security anti-pattern: the more resets your support team handles manually, the more social-engineering surface area you have. Automating the flow is safer, not less safe, when it's designed properly.
What we shipped
The flow itself is deliberately boring, which is the highest compliment we can pay it. From the sign-in screen, users open the forgot password page, enter the email associated with their account, and submit the request. If the address matches an account, a reset email goes out; either way, the UI confirms the request was received. Reset a Forgotten Password
A few design choices worth calling out:
- We always show the same confirmation, regardless of whether the email matched an account. This is table stakes for avoiding account enumeration, but it's the kind of thing that's easy to get wrong under deadline pressure.
- The reset link is the credential, not a temporary password we email in plaintext. Emailed passwords are one of those patterns that feels convenient right up until it shows up in a postmortem.
- The form is a single field. No security questions, no CAPTCHAs on the initial request. We'd rather rate-limit server-side than make the ninety-ninth-percentile user prove they're human.
Step-by-step instructions live in the help center — this post is about the why, not the how.
What's next
Self-serve reset is the foundation, not the finish line. The next things on our list are passkey support (so fewer users need to reset in the first place), clearer session-invalidation semantics after a reset, and better observability into where users drop off in the flow. If you have thoughts on any of the above, we're listening.