Alerts

Alerts let you watch your Session Replay data and get notified the moment something goes wrong in your product, a spike in failed requests, a surge of errors, a rash of rage clicks, or an API that suddenly slows down. Instead of manually scrubbing through sessions to find problems, you define what bad looks like once, and DevRev watches for it around the clock and tells you when it happens.

Each alert is powered by a monitor.

A monitor continuously asks a simple question: "In the last few minutes, how many sessions matched my filter, and is that count above (or below) my threshold?"

When the answer crosses the line you set, the alert fires and the people who own it are notified with a direct link to the exact sessions so they can start investigating in one click.

Key concepts

What a monitor watches

You point a monitor at one platform and one type of session data:

Web and Mobile are the two platforms that matter for a monitor. Mobile covers both iOS and Android as a single category, the data types, fields, and behaviour are identical across the two, so you don't pick an operating system, you pick mobile. A mobile monitor watches your iOS and Android sessions together.

For each type you write a filter that decides what counts, for example, only requests to your checkout endpoint that returned a 5xx, or only crashes on a specific screen.

The condition

On a fixed schedule, the monitor counts the session records matching your filter over a rolling window, then compares that count against a threshold. The comparison result, met or not met, is what drives the alert.

Keep the evaluation interval at or below the look-back so consecutive windows overlap and no data slips through a gap between checks.

So a monitor might read: "Every 1 minute, count checkout 5xx responses over the last 10 minutes; the condition is met when that count is greater than 20."

Alert lifecycle

Every monitor has exactly one alert attached to it. On each evaluation the monitor computes whether the condition is met, and the alert moves through a small state machine. There are four states:

• Inactive - the condition is not being met. All quiet.

• Pending - the condition just started being met, but hasn't been met long enough to fire yet (a holding state to filter out momentary blips).

• Active - firing. The condition has been met long enough to be considered real.

• Recovering - the condition has stopped being met, but the alert is held up a little longer before going quiet (a buffer against flapping).

Two optional timing settings shape the transitions:

• Pending duration - how long the condition must stay met before the alert moves from Pending to Active. Default 0s; up to 30 minutes.

• Keep firing for - how long the alert stays up (in Recovering) after the condition stops being met, before it returns to Inactive. Default 0s; up to 30 minutes.

The transitions work like this:

• Inactive → the condition becomes met: if pending duration is 0s, the alert goes straight to Active and fires immediately. If pending duration is greater than 0s, it goes to Pending first.

• Pending → condition stays met for the full pending duration → Active. But if the condition stops being met while Pending, the alert drops straight back to Inactive, it never fired, so nothing is raised for a blip that didn't last.

• Active → the condition stops being met: if keep firing for is 0s, the alert goes straight to Inactive. If it's greater than 0s, it goes to Recovering first.

• Recovering → condition stays clear for the full keep-firing-for duration → Inactive. But if the condition becomes met again while Recovering, the alert jumps back to Active without re-entering Pending, so a metric hovering around the threshold stays as one continuous alert instead of flapping.

In short: 'pending duration' debounces the start of an alert, and 'keep firing for' debounces the end. Set both to 0s (the default) and the alert simply tracks the condition, Active whenever met, Inactive whenever not.

Create an alert

1. Go to the Monitors page (/monitors) and select Create monitor.

2. Give it a clear name and, optionally, a description that will show up in listings.

3. Choose the platform (Web or Mobile) and the type of data to watch. Mobile covers iOS and Android together.

4. Write the filter for what you want to count (see Writing filters below).

5. Set the condition - the comparison operator and the threshold value.

6. Set the timing - evaluation interval and look-back, and optionally pending duration and keep firing for.

7. Assign one or more owners so it's clear who's responsible for the monitor.

8. Save. The monitor starts evaluating on its next cycle, and its alert appears on the Alerts page (/alerts).

Tip: If you're not sure what threshold to use, start by looking at how often the pattern normally occurs over the last day, then set a threshold that sits comfortably above the normal band but below a genuine spike. A slightly loose threshold with a 5–10 minute look-back is usually better than a tight one that flaps.

Writing filters

The filter is what makes an alert precise. It narrows a monitor down from "all sessions" to exactly the pattern you care about.

A filter is a set of conditions on the fields available for the platform and data type you chose. The fields you can filter on differ by data type, so pick the data type first, then use the reference tables below to see what you can match.

Supported fields by data type

Each field has a type that decides how you can match it:

• Text/keyword - exact value, or an IN list of several values.

• Number - exact value or an IN list. Two fields (marked range below) additionally support the > and < operators for open-ended and banded ranges.

• Boolean - true or false.

Web page (UI) events

Web network requests

Web console messages / custom events

These data types let you count console messages or SDK custom events on web, but field-level filtering is not applied - a monitor on either type counts all records of that type in the window. If you need to filter on a specific value, use page events or network requests instead.

Mobile In-app (stock) events

Mobile custom events

Mobile API response times

Matching a value

Match a field to an exact value, and combine conditions with AND:

• A failed request to a specific endpoint: request_url:"https://api.example.com/v1/checkout" AND response_status:500

• Rage clicks anywhere on the page: is_rage:true

• A specific mobile crash on the checkout screen: exception_class_name:NullPointerException AND screen_name:"CheckoutScreen"

• A custom event failing on a specific screen: event_name:signup_failed AND screen_name:"SignupScreen"

• A crash confined to one app version: event_type:crash AND app_version:"4.12.0"

Matching several values at once

Use an IN list when any of several values for the same field should count - for example, any server error:

response_status: IN [500 501 502 503 504 505]

This is also how you express "not X": since there's no "not" operator, list the values you do want. For example, to count every method except GET:

request_method: IN [POST PUT PATCH DELETE]

Matching a range (slow requests and slow APIs)

Two numeric fields support the > and < operators so you can alert on latency: duration (web network requests) and round_trip_time (mobile API response times). Values are in milliseconds.

• Web requests slower than 2 seconds: duration > 2000

• Web requests faster than 30 seconds (i.e. ignore true timeouts): duration < 30000

• Web requests in a 2–30 second band: duration > 2000 AND duration < 30000

• A slow checkout call specifically: request_url:"https://api.example.com/v1/checkout" AND duration > 250

• Mobile API calls slower than 3 seconds: round_trip_time > 3000

• Mobile API calls in a 0.5–3 second band: round_trip_time > 500 AND round_trip_time < 3000

A few rules for ranges:

• Only > and < are available (there is no >= or <=), and they only work on duration and round_trip_time. Using them on any other field is rejected when you save the monitor.

• Write a space around the operator (duration > 2000), not a colon.

• When you set both bounds, keep them in the same condition joined by AND. Splitting a range so the minimum ends up above the maximum (an impossible range) is rejected when you save, rather than silently matching nothing.

• For status codes and other whole-number fields that aren't ranges, list the values with IN instead: response_status: IN [500 501 502 503 504 505].

Matching a URL prefix

Quote the URL and end it with * to match everything under a path:

request_url:"https://api.example.com/v1/orders/*"

A few things to keep in mind

• Combine conditions with AND - Writing two conditions next to each other also means "and".

• To exclude values, list what you do want instead - There is no "not" operator - enumerate the values you care about with an IN list, or flip your condition (for example, alert when a success count drops below a threshold).

• Group values of the same field with IN - you can't mix different fields in a single "either/or". If you need "either this field or that field", create two monitors.

• Use only the fields listed for your data type - A field that doesn't belong to the chosen platform and data type is rejected when you save the monitor.

• Always quote URLs - and values that contain slashes, spaces, or punctuation.

If a filter matches nothing, the alert will never fire - so it's worth confirming your filter matches real, recent sessions before relying on it.

Acting on alerts with workflows

Alerts don't send notifications on their own. Instead, every alert state change is an event you can act on in a workflow - so you decide what happens, and where, when an alert fires, recovers, or clears. This is more flexible than a fixed notification: the same event can post to a channel, page an on-call rota, open a ticket, or trigger any other automation you build.

To react to alerts, build a workflow triggered by an alert state change. When an alert changes state, the workflow receives details about what happened, including:

• The alert's new status (pending, active, recovering, or inactive).

• The monitor it belongs to (its name and identifier).

• The time the state changed and when the alert last became active.

From there the workflow can do whatever you need - for example:

• Post a message to a team channel when an alert becomes Active, and a follow-up when it returns to Inactive.

• Open or update a ticket for the owning team while an alert is firing.

• Include a Session Replay link in the message, scoped to the alert's time window, so responders can jump straight to the affected sessions.

Because it's a workflow, you control the routing, the wording, and the conditions — including which state changes are worth acting on (many teams act only on the transition into Active and back to Inactive, and ignore the intermediate Pending/Recovering steps).

Manage alerts

There are two pages, one for the rules and one for what they're currently doing:

• Monitors page /monitors - where you create, view, and maintain the monitors themselves.

• Alerts page /alerts - where you see the live state of each monitor's alert i.e which alerts are currently Active, which are Pending or Recovering, and their recent history. Check here to see what's firing right now and to review whether a monitor is behaving as expected.

Troubleshooting

Q.The alert is too noisy
Increase the pending duration so the condition has to hold for longer before the alert becomes Active. A momentary spike that clears within the pending window drops straight back to Inactive and never fires.

Q. The alert flaps on and off
Increase keep firing for. When a metric hovers right around the threshold, this keeps the alert steady instead of toggling repeatedly.

Q. The alert never fires
Check these in order:

1. Does the filter match real data? Confirm the field names and values actually occur in your recent sessions. A filter that matches nothing can never fire.

2. Is the evaluation interval smaller than or equal to the look-back? If the window is shorter than the check frequency, evaluations can miss data. A look-back of 5–10 minutes is a safe starting point.

3. Is the threshold realistic? Compare it against how often the pattern normally occurs. A threshold set far above real traffic will never be reached.

Q. I set a threshold but I'm not sure it's right
Look at how frequently the pattern occurred over the last 24 hours, scale that to your look-back window, and set the threshold just above the normal range. Leave some headroom so ordinary fluctuations don't trip it, but keep it low enough to catch a genuine incident.