Live

Session Replay capturing more sessions than configured

0

Amplitude Session Replay captured more sessions than the configured sample rate or targeting conditions allowed for some web projects. Amplitude reports that the issue is resolved. The incident lasted 28 minutes.

State

Resolved

Started

Lasted

28 min

Worst impact

Degraded

Timeline

3 updates
14:5615:0315:1015:1715:24
DegradedUpdate postedTimes in UTC

Identified

19 min 68%

Monitoring

9 min 32%

Updates

Times in UTC

As posted by Amplitude

Resolved

We've now confirmed that the fix is fully resolved. Session Replay is now capturing sessions according to each project's configured sample rate and targeting conditions. We apologize for any impact this may have caused and thank you for your patience while we investigated.

Monitoring

We've deployed a fix for the issue causing some web projects to capture more Session Replay sessions than their configured sample rate or targeting conditions allow. New sessions should now be captured according to your settings. We're monitoring closely and will provide another update once we've confirmed the issue is fully resolved.

Identified

We’ve identified an issue affecting Session Replay for some web projects. Since October 28, 2026, some projects may be capturing more sessions than their configured sample rate or targeting conditions allow, which can increase Session Replay usage. Our engineering team has identified the cause and is working on a fix. We’ll provide an update as soon as possible, and we’re reviewing the impact on Session Replay usage for affected customers.

Affected components

1
Session Replay

Amplitude in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

23

Days with an incident

24

Median duration

1 h 13 min

This incident

61% shorter than the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

6 h 5 min
median 1 h 13 min
90 days agoToday

Other Amplitude incidents

All incidents

Follow Amplitude

Your coding agent knows when Amplitude is down, and tells you when a failure is theirs, not yours. You can also get Amplitude incidents in a feed reader or in Slack.

Prompt
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.

Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.

Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "amplitude" and tell me if Amplitude has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.

Paste this into any coding agent. It adds the server with its own MCP setup.

RSS
https://outages.live/feed.xml?providers=amplitude
Slack
/feed subscribe https://outages.live/feed.xml?providers=amplitude

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane