Security / Anomalies
Key & traffic anomalies
Your live publishable key ships in client code, so a leaked or scraped key can be picked up and hammered by traffic that has nothing to do with your real users — a botnet, a credential-stuffing run, or a plain flood. Onelo watches for exactly that. A background job looks at the last 24 hours of traffic per key, and when the shape of it stops looking like normal use, it raises an anomaly and files it in your Security events feed under Key anomaly. This is fully automatic — there is nothing to install, enable or configure.
What it watches for
Four independent signals run against the traffic for each key. Each one has three severity levels — soft, medium and extreme — with the exact thresholds below. A signal can trip on its own; you don't need several to line up.
| Signal | Detects | soft | medium | extreme |
|---|---|---|---|---|
ip_diversity | Many unique /24 IP blocks on one key — the fingerprint of a botnet or a leaked key spread across machines. | ≥ 10 blocks | ≥ 30 blocks | ≥ 100 blocks |
ua_diversity | Many unique user-agents on one key — real apps present a handful; a swarm of bots presents dozens. | ≥ 10 agents | ≥ 20 agents | ≥ 50 agents |
signin_failure_ratio | A high share of failed sign-ins — the signature of a brute-force or credential-stuffing run. Both a minimum attempt count AND a fail ratio must hold, and the attempt floor rises with severity. | ≥ 50 attempts AND ≥ 70% fail | ≥ 100 attempts AND ≥ 80% fail | ≥ 200 attempts AND ≥ 95% fail |
sustained_volume | Extreme sustained request volume over the whole 24h window — a leak or DDoS signal even when the other signals look clean (e.g. a single-IP flood or a paid botnet). | ≥ 10,000 req / 24h | ≥ 30,000 req / 24h | ≥ 100,000 req / 24h |
signin_failure_ratio carefully: the minimum attempt count is not a flat 50. It steps up per severity — 50 attempts for soft, 100 for medium, 200 for extreme — and each severity pairs its own attempt floor with its own fail ratio (70% / 80% / 95%). A short, mostly-failing burst reads as a dev fumbling a password; hundreds of attempts at a 95% fail rate does not.How you're notified
A cron runs every 15 minutes (*/15 * * * *). It scans each app's recent traffic, detects anomalies against the thresholds above, and — for anything at medium or extreme severity — is marked medium or extreme. Soft anomalies are recorded too, so a mild uptick doesn't become inbox noise. Every anomaly, at any severity, also lands in your Security events feed under the Key anomaly category, where you can see the key hint, the signal that tripped and the measured numbers. No configuration is involved — the moment you have live traffic, this is already running.
Not your dev laptop
The thresholds are tuned so that ordinary development doesn't trip them. Traffic coming from a single /24 IP block — one office or home network — is exempt from the IP signal, and a very small set of user-agents (your browser plus a couple of test tools) is exempt from the UA signal. Likewise a 50/50 win-and-fail sign-in split while you're debugging login won't flag, because real attacks fail at a far higher rate. You building against your own key on your own machine looks nothing like a botnet, and Onelo treats it accordingly.
If you get flagged
A medium or extreme anomaly on a live key almost always means the key is out in the wild and being abused. The fix is to rotate the key: issue a fresh publishable key, ship it in your next build, and revoke the leaked one so the abusive traffic dies at the door. The rotation steps live in Going live. If the traffic looks legitimate — a genuine spike you can account for — you can leave it; the anomaly is a heads-up, not an automatic block.