Features / Alerts
Session replay alerts for rage clicks and errors
The question you'd ask every day if asking weren't the hard part. Ask it once and let it stand.
What it does
- Conditions, not keywords An alert is built from the same filters as a search — URL, error status, rage clicks, dead clicks, session duration — combined, so “checkout sessions with a failed payment request” is one saved watch, not a search you re-run.
- Preview before you commit While composing a condition, see how many of your recent tapes would have matched it — the difference between an alert that fires twice a year and one that fires forty times a day is visible before you save it.
- A match history, not just a notification Every alert keeps its own log of what it caught and when, so a watch you set three weeks ago is still answerable — “has this actually fired, and on what” — without digging through a general activity feed.
- Agents can create these themselves Over MCP, an agent that diagnoses a problem can also set the alert that catches the next occurrence — closing the loop from “found it once” to “told automatically from now on” in the same conversation.
The failure mode of most session replay tools isn’t that they can’t show you a problem — it’s that showing you a problem requires you to go looking for one. Most teams check a dashboard when something is already on fire, which means the recording of the actual first occurrence sat there, unread, for however long it took someone to notice a pattern from customer complaints instead.
Alerts move the checking from a habit you have to maintain to a condition that stands on its own.
What a condition is built from
An alert is the same filter logic as a tape search, saved: a URL match, an
error condition, a rage-click or dead-click threshold, a minimum session
duration, any combination. “Tell me when a session on /checkout has a
failed request” is one alert. “Tell me about sessions longer than five
minutes with no navigation” is another. Neither requires remembering to check
anything — the condition is evaluated as sessions finalize, and a match
surfaces on its own.
Previewing before you commit
The easiest way to make an alert useless is to set it too broad, and the easiest way to miss the problem entirely is to set it too narrow. Composing one shows a live count — how many of your last twenty or so tapes would have matched — before you save it, so you find out you’ve built a firehose (or a condition that will never fire) while it’s still free to fix, not after a week of noise or silence.
A history worth checking, unprompted or not
Every alert keeps its own match log. That’s a small thing that solves a real annoyance: three weeks after setting a watch, “did this ever actually fire” is a question with an immediate answer instead of a scroll through a general activity feed hoping to spot it.
Where an agent fits in
The interesting version of this isn’t a human composing conditions in a form — it’s an agent that just diagnosed a bug creating the alert that catches the next occurrence, in the same breath. Over MCP, the create/delete alert tools are available to any connected client, which means “find this, fix this, and tell me if it happens again” can be one request instead of three separate visits to the product.
Asking your agent
$ claude "set an alert for failed payments on checkout"
▸ usertapes create_alert(
name: "Checkout payment failures",
url_contains: "/checkout",
has_errors: true
)
← alert created · 3 of the last 20 tapes would have matched
See session replay over MCP for the full setup.