diff --git a/integrations/observability/prometheus-v2.mdx b/integrations/observability/prometheus-v2.mdx
index b6c924c3..f90cd9d0 100644
--- a/integrations/observability/prometheus-v2.mdx
+++ b/integrations/observability/prometheus-v2.mdx
@@ -191,6 +191,12 @@ The different histogram metrics can all be used to compute averages. For example
 sum by(type) (rate(checkly_browser_check_web_vitals_seconds_sum{name="Check Name"}[30m])) / sum by(type) (rate(checkly_browser_check_web_vitals_seconds_count{name="Check Name"}[30m]))
 ```
 
+<Note>
+The histogram metrics exposed by the Checkly exporter only ship a single `le="+Inf"` bucket — they don't include the finite bucket boundaries that `histogram_quantile()` needs. That means percentile queries such as `histogram_quantile(0.95, rate(checkly_api_check_timing_seconds_bucket[5m]))` will not return a useful value.
+
+Use the `_sum / _count` average pattern shown above for aggregations. If you need percentile-style latency signals, compute them in your alerting layer from the raw check run data rather than from the `_bucket` series.
+</Note>
+
 ## Heartbeat Metrics
 
 [Heartbeat monitors](/detect/uptime-monitoring/heartbeat-monitors/overview) are passive checks that wait for your scheduled jobs and automated processes to send a ping. The Prometheus exporter includes heartbeat checks in the standard `checkly_check_status` and `checkly_check_result_total` metrics, plus two heartbeat-specific gauges designed for [dead man's switch](https://en.wikipedia.org/wiki/Dead_man%27s_switch) alerting.
diff --git a/learn/playwright/authentication.mdx b/learn/playwright/authentication.mdx
index 61f6d709..f8761086 100644
--- a/learn/playwright/authentication.mdx
+++ b/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, one-time passcodes sent via 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 on its own, so you need a way to fetch the code from outside the browser and then 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.
diff --git a/learn/playwright/bypass-totp.mdx b/learn/playwright/bypass-totp.mdx
index 069aea54..f3a91ede 100644
--- a/learn/playwright/bypass-totp.mdx
+++ b/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 **authenticator app / TOTP** flows only. If your login uses an OTP delivered by **SMS or email**, `otpauth` can't help — the code is generated server-side and delivered out of band. See the [SMS and email one-time passcodes](/learn/playwright/authentication#sms-and-email-one-time-passcodes) section of the authentication guide for the patterns we recommend (test-mode bypass, programmable inbox providers, or reading the code from your own backend).
+</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.