Alerts and anomaly detection: know before your users tell you

Nobody watches a dashboard all day. So the moments that matter most — a release that starts crashing, a funnel step that quietly stops converting, an SDK update that breaks event tracking — usually surface hours later, once someone thinks to look, or once a user complains. Vexo now closes that gap: it evaluates your key metrics on a schedule and tells you the moment something moves.

There are two ways to be alerted, and they solve different problems. Threshold alerts fire when a metric crosses a line you set. Anomaly detection fires when a metric strays from its own recent behavior — no line to guess. You can use either, or both, per app.

Threshold alerts: draw a line, get pinged when it's crossed

Threshold alerts are the right tool when you already know what "bad" looks like. You enable a type, set a number, and Vexo compares the live metric against it. Every alert is off until you turn it on, and the types available in Settings → Alerts are:

• Error spike — fires when errors in the last hour reach or exceed your count.
• Crash-free sessions drop — fires when the crash-free rate falls below your percentage.
• D1 retention falloff — fires when day-1 retention drops below your percentage.

Each type watches the window that fits it: error spikes are evaluated hour-by-hour, crash-free over a day, and retention over its cohort. There's also a funnel step conversion falloff alert that watches a specific step of a specific funnel widget and fires when its conversion drops below your threshold — configured through the API today, since it needs to point at a particular widget and step.

Anomaly detection: for when you can't pick a number

A fixed threshold is useless for metrics whose "normal" drifts. What's a healthy daily event count for an app that's doubling every month? What error rate is fine on a Tuesday but alarming on a Sunday? Anomaly detection sidesteps the guess: each metric is scored against its own recent daily baseline.

Under the hood it's a rolling z-score. Vexo takes the recent daily series for a metric, computes the mean and standard deviation of every day except the latest, and measures how many standard deviations the latest day sits from that baseline. You set the sensitivity in standard deviations — lower is more trigger-happy, higher only flags the truly extreme days. It's deliberately a plain, transparent statistic: no model to train, and it holds up on the short histories most apps have. A flat baseline (common on very low-traffic apps) is treated as "can't judge" rather than firing on any change at all.

Four metrics are watched this way, each in the direction that actually means trouble:

• Event volume anomaly — either direction. A sudden drop is often a broken instrument or a bad release; a spike can be a viral moment or a bot flood.
• Active users anomaly — either direction, for the same reasons.
• Crash-free rate anomaly — drops only. You only want to hear when it gets worse.
• Error rate anomaly — spikes only.

The event-volume and active-users alerts are the ones that catch the failure mode dashboards miss: not a value that's wrong, but data that stopped arriving. If an SDK upgrade or a shipped bug quietly kills your tracking, a threshold on "too high" will never notice. A baseline that expects yesterday's volume will.

How evaluation runs

Alerts are evaluated on a schedule — every hour, in the background, across all your enabled configs. You don't poll anything or run a query. To keep a persistent problem from paging you every hour, each alert type has a per-app cooldown (six hours by default): once it fires, it stays quiet until the cooldown passes, so an ongoing incident is one notification, not twelve.

Where alerts land

Every alert is emailed to the app owner, and posts to Slack if you've connected it. Threshold alerts additionally post to a connected Microsoft Teams channel. Connect the channels you want in the app's settings; email always works out of the box, and Slack and Teams are best-effort on top — if a chat delivery ever fails, it never blocks the email.

The message itself is concrete: which alert fired, for which app, the value that triggered it, and how it compared to your threshold or baseline — enough to know whether to drop what you're doing without opening the dashboard first.

Email digests: the scheduled pulse

Alerts are for the exceptions. For the steady rhythm, turn on an email digest under Settings → Notifications. It's a scheduled summary of the app's key metrics, notable changes, and top errors, each shown against the previous period so you see the trend, not just the number.

• Cadence — daily (compared against the prior day) or weekly (against the prior 7 days).
• Recipients — a comma-separated list of emails; leave it blank and it goes to the app owner.

It's the report someone would otherwise assemble by hand every Monday — your metrics, the deltas, and what broke — delivered on its own.

Getting started

1. Open your app's Settings in the Vexo dashboard.
2. Under Alerts, enable the threshold alerts you want and set their numbers.
3. Under Notifications, enable the anomaly alerts you want and tune each one's sensitivity, then switch on the daily or weekly digest.
4. Connect Slack or Microsoft Teams if you want alerts in chat as well as email.

Questions or feedback? Reach out at hello@vexo.co or join our Discord.