Fill gaps from assistant conversations: SMS/email OTP and Prometheus percentiles

learn/playwright/authentication.mdx

@@ -138,6 +138,19 @@ Notice the following in this code example:
 
 As mentioned, there is some prep you need to do. Refer to our full [article on 2FA login](https://www.checklyhq.com/learn/playwright/bypass-totp/) for all instructions.
 
+### SMS and email one-time passcodes
+
+Unlike TOTP codes, one-time passcodes sent by SMS or email cannot be generated inside your test. The code is only known after the provider sends it. Playwright cannot read a text message or open a mailbox, so the test has to fetch the code from somewhere else and type it into the login form.
+
+You have a few practical options:
+
+- **Use a test-only bypass.** The most reliable approach is to work with your application team to add a test-mode account, a shared static code, or a header/query flag that skips the SMS/email step in a non-production environment. This keeps the test deterministic and avoids depending on third-party delivery.
+- **Poll a programmable inbox.** For email OTP, sign up your test user with a mailbox that exposes an API (for example, Mailosaur, Mailslurp, or a Gmail account you can query via the Gmail API). In your Playwright test, poll the API for the most recent message, extract the code with a regex, and `fill()` it into the OTP input.
+- **Poll a programmable phone number.** For SMS OTP, use a provider that lets you receive SMS via API (for example, Twilio or a similar service) against a dedicated test number, then poll for the latest message body and extract the code.
+- **Read the code from your own backend.** If your app stores the last issued OTP in a database or exposes it on an internal endpoint in staging, query that from the test instead of the delivery channel.
+
+Whichever path you pick, wrap the fetch step in a short polling loop with a timeout so the test fails clearly if the code never arrives, and store any credentials or API keys for the inbox provider as [environment variables](/platform/variables) rather than committing them to the repo.
+
 ## Passkey & **WebAuthn**
 
 Passkeys are a fairly recent authentication scheme. Passkeys are passwordless, so passwords can’t be stolen or phished. There is also no need to memorize a passkey. Often, a passkey is tied to biometric data: every time you authenticate on some app or service with Face ID or Touch ID or using [YubiKey](https://www.yubico.com/) you are using a passkey.

learn/playwright/bypass-totp.mdx

@@ -38,6 +38,10 @@ Following the flow, people log in with their credentials and are prompted with a
 
 And indeed, testing a passcode coming from a mobile application or SMS is challenging, but as it turns out, authenticator apps don’t include as much magic as I initially thought!
 
+<Note>
+This article covers TOTP codes from authenticator apps only. `otpauth` cannot produce a passcode sent by SMS or email, because the server creates it and delivers it out of band. For those flows, see [SMS and email one-time passcodes](/learn/playwright/authentication#sms-and-email-one-time-passcodes).
+</Note>
+
 ### Authenticator apps and TOTP
 
 Let’s look at GitHub’s 2FA flow. When setting up 2FA with an authenticator app, the service greets you with the following screen.