How-to
Configuring Alert Thresholds
How to tune detector sensitivity and set up notification routing.
Jump to section
Default rules
Every new tenant gets the full set of default detector rules with thresholds tuned against a large reference storefront, then scaled automatically to your own traffic volume. These work out of the box for most SFCC deployments.
A few high-power detectors ship disabled (Path Traffic Spike, IP Fan-out, Method Shift, Distributed Path Abuse, Inventory Hoarding, Search Abuse, UA Rotation) so you can review their thresholds against your own traffic shape before enabling them. See How Detectors Work for the full catalogue and defaults.
Editing a rule
Go to Rules in the sidebar. Each rule card shows its current thresholds and an enable/disable toggle.
- Enable/disable: click the toggle switch on each rule card
- Notification routing: expand the "Notification routing" section on each rule to set per-rule email and webhook overrides
- Inline threshold editing: click the pencil icon next to any rule's threshold block to switch to edit mode. Update values and save directly from the Rules page.
- "Requires field" badges: rules that depend on a specific Logpush field show a badge when that field is missing from your job, so you know a detector is inactive before you wonder why it never fires. See HTTP Methods and Required Logpush Fields.
Changes take effect on the next detector evaluation (within 60 seconds for fast detectors).
Key thresholds to tune
| Detector | Threshold | When to change |
|---|---|---|
| ASN Spike | per-network-type multiplier | Lower a type (e.g. cloud) for earlier warnings; raise if a type produces false positives |
| 499 Rate | ratio_threshold | Lower if your site has very low natural 499s; raise for sites with slow responses |
| Cache Bypass | multiplier | Depends on your cache mix; let the source baseline calibrate first |
| Slow Burn | total_deviation_pct | Lower to catch subtler growth patterns |
| Bot Score | bot_ratio_threshold | Lower to catch ASNs with moderate bot traffic; raise to reduce noise |
| TLS Weak Protocol | weak_ratio_threshold | Lower for stricter compliance; raise if you have legitimate legacy clients |
| Path Entropy | entropy_threshold | Lower for broader crawl detection; raise if legitimate bots traverse many paths |
| Challenge Solving | solve_rate_increase_pct | Lower to catch subtler evasion upgrades |
| Certificate Expiry | expiry_thresholds_days | Adjust the day thresholds for earlier or later warnings |
Expected surges: use campaign windows, not looser thresholds
If a sale, product drop, or email send is going to spike your traffic, do not raise thresholds to survive it (you would be blind for weeks after). Declare a campaign window instead: the volume-driven detectors stay quiet for that window only, security detectors keep watching, and everything suppressed is logged for review.
Warmup and baselines
New sources have a warmup period (60 minutes for fast detectors, 6 hours for hourly detectors) during which detectors are suppressed. This prevents false positives from the initial backfill batch when a Logpush job is first enabled. Baselines auto-calibrate from your real traffic after about 4 hours.
Notification routing
Three-tier routing, checked in order:
- Per-certificate — set on the Certificate Detail page (certificate alerts only)
- Per-rule — set on the Rules page via the expandable "Notification routing" section
- Tenant defaults — set on the Settings page under "Notification defaults"
Per-rule overrides support email and webhook. Tenant defaults additionally support Microsoft Teams and Slack — see Sending Alerts to Teams and Slack.