How to get alerted the moment your app rating drops (before it costs you installs)
Averages move too slowly to warn you. Here's how to catch a rating crash or a negative-review spike within hours, using a 24h-vs-28-day baseline and a cooldown so one dip doesn't storm your channels.
The Argus Team
Reply Argus
By the time your store average visibly moves, the damage is already priced into your install rate. A cumulative rating is the sum of every review you have ever received, so a bad build or an outage can bury dozens of one-star reviews under thousands of old five-stars and never register as more than a rounding change. You find out from the average days or weeks late, if at all. The signal you actually want is not the average. It is the derivative: how today compares to your recent normal.
This guide explains how to detect a rating drop in near real time, why a raw threshold like 'alert me if the average falls below 4.5' is the wrong tool, and how Reply Argus watches each app's last 24 hours against a 28-day baseline so a genuine crash pings your team within hours while ordinary daily noise stays quiet.
Why doesn't the store average warn you in time?
Because the average is a lagging, heavily damped indicator, and the thing you need to react to is a sudden change in incoming sentiment, not the slow settling of a lifetime total. Consider an app with 20,000 reviews at a 4.6 average. A terrible day that brings in forty one-star reviews moves the cumulative average by roughly a hundredth of a star. You would never notice it on the store page. But those forty one-stars are the leading edge of a problem that, left unanswered, will keep arriving tomorrow and the day after, and every prospective installer reading your most-recent reviews sees them first.
A fixed threshold does not fix this. Set it high and it screams on normal variance; set it low and it stays silent through a real crash until it is far too late. The only threshold that means anything is one defined relative to that specific app's own recent behavior. A drop from a 4.8 daily norm to 4.1 matters. A wobble around a 3.2 norm does not. The baseline has to be per-app and rolling, not a number you pick once.
How does the 24h-vs-28-day detector actually work?
Reply Argus compares each app's last 24 hours of reviews against its own trailing 28-day baseline, and fires when the recent window diverges sharply from normal in either of two directions: a rating crash (the last day's average star rating falls well below the 28-day norm) or a review-flood spike (a sudden surge in negative-review volume relative to the baseline rate). The 28-day window is long enough to smooth out weekday and weekend rhythm, and the 24-hour window is short enough to surface a problem while you can still act on it. Here is the shape of the check.
- 1
Build the baseline
For each enabled app, Argus rolls a 28-day baseline of review rating and volume. This is the app's own normal: what an ordinary day looks like for this specific listing, in this specific market, at this specific point in its life. Nothing about it is a global constant, so a niche app with a 3.4 norm and a hit with a 4.9 norm are each judged against themselves.
- 2
Measure the last 24 hours
Every sync, the recent window (the last day of incoming reviews) is scored against that baseline: how far has the average rating dropped, and how much has the rate of negative reviews spiked? Both axes are watched, because a crash and a flood are different failure modes. A bad release shows up as a rating crash; a review-bombing or a viral complaint shows up as a volume spike.
- 3
Apply the guardrails
A move only counts as an anomaly if it clears every guardrail at once (see below): a large enough relative move, an absolute floor so a trivial dip cannot trip it, and a minimum baseline so a brand-new or tiny app with almost no history cannot false-fire on a single stray review. All three must hold. This is what keeps the signal honest.
- 4
Fire once, then cool down
When the guardrails are cleared, Argus sends an anomaly alert to your connected channels and then holds a 7-day cooldown for that app. One genuine problem produces one alert, not a rolling storm of reminders every hour while you are already working the fix.
What stops it from false-firing on a tiny app?
A detector that only asks 'did the number move a lot in percentage terms' will betray you on small samples. If an app got two reviews yesterday and both were one-star, the relative drop is enormous, but two reviews is not a trend. So the anomaly test is a conjunction of three conditions, and all of them have to be true before anything fires:
- A relative move. The last 24 hours has to diverge meaningfully from the 28-day baseline, not by a hair. A small everyday fluctuation around the norm is exactly the noise the baseline exists to absorb.
- An absolute floor. On top of the relative move, the drop (or the negative-volume spike) has to clear an absolute size. This stops a jitter that happens to be large in percentage terms, but tiny in real terms, from tripping the alert.
- A minimum baseline. The app has to have accumulated enough review history for the baseline to mean anything. Below that floor, a single bad review can swing the whole window, so Argus stays silent rather than cry wolf on a listing that simply does not have the volume yet.
No config, no tuning
The detector is deterministic. There is nothing to configure, no sensitivity slider to tune, no threshold to guess wrong. The three guardrails are fixed and applied identically to every app, so the alert you get is one Argus is confident about rather than one you accidentally mis-set. This is by design: an alerting system you have to babysit is one you will eventually stop trusting.
Where do the alerts go, and how noisy are they?
Alerts go wherever your team already is. Connect a channel once and anomaly alerts route to it: Slack, Telegram, Discord, or a raw webhook you can forward into any system you like. The webhook payload is a signed JSON POST (the same anomaly.detected event available to the API), so you can drive a pager, open an incident, or fan it out to your own tooling. You do not have to sit inside Reply Argus watching a dashboard; the point of the alert is that it comes to you.
The 7-day per-app cooldown is what makes the alerts livable. A rating crash is rarely a single-hour event, and without a cooldown a sustained bad week would generate an alert on every sync. Instead you get one clear ping when the anomaly first crosses the line, and then quiet while you deal with it, which is exactly when you do not want your channels buzzing. If a fresh, distinct anomaly appears after the cooldown lapses, it can fire again.
The alert is the trigger, the reply is the recovery
Pair the alert with auto-drafting. Because a rating-drop alert usually means a wave of similar complaints just landed, the fastest recovery is to have grounded replies already drafted and waiting for approval when you open the app. The alert tells you something broke; the drafts let you answer everyone who reported it within the same hour.
Who can use it?
Rating-drop alerts are available on the Indie tier and up. Every enabled app is watched automatically once a channel is connected; there is nothing per-app to switch on. A disabled (paused or over-limit) app is not watched, because a frozen app is not syncing reviews in the first place.
Frequently asked
- How quickly will I hear about a rating drop?
- Within hours, not days. Argus checks the last 24 hours against the 28-day baseline on each sync, so a genuine crash or a negative-review flood surfaces on the next sync after it starts, rather than waiting for the cumulative store average to move. The store average would take days or weeks to reflect the same event, if it ever visibly did.
- Why not just alert me when my average falls below a fixed number?
- Because a fixed threshold has no idea what normal is for your app. Set it high and it fires on ordinary variance; set it low and it stays silent through a real crash. Argus compares each app to its own trailing 28-day baseline, so a drop is judged relative to that specific listing's normal instead of an arbitrary line you had to guess.
- Will a brand-new app with only a few reviews spam me with alerts?
- No. The detector requires a minimum baseline of review history before it will fire, so a small or new listing where a single stray review swings the whole window stays silent. An alert only goes out when a relative move, an absolute floor, and that minimum baseline are all satisfied at once.
- Where do the alerts arrive?
- Any channel you connect: Slack, Telegram, Discord, or a raw webhook. The webhook version is a signed JSON POST (the anomaly.detected event), so you can route it into an incident tool, a pager, or your own systems and verify it before acting.
- Will one bad week flood my channel with repeated alerts?
- No. Each app has a 7-day cooldown after an alert fires, so a single sustained problem produces one clear ping rather than a repeated alarm on every sync. A distinct new anomaly can fire again once the cooldown has lapsed.
- Is there anything to configure?
- No. The detector is deterministic with fixed guardrails applied identically to every enabled app. There is no sensitivity setting to tune and no threshold to get wrong; you connect a channel once and every enabled app is watched automatically. It is on the Indie tier and up.
Try it
Let Argus draft your next reply.
Watch it answer a real review in your voice. 10-day trial, no card to begin.
Keep reading
App Store Reviews Not Showing? The Full Fix List for Apple and Google Play
App Store or Google Play reviews not showing? Here's every real cause — moderation delay, wrong country storefront, filtering, rating lag, cache — and the fix.
Read moreAre App Store Reviews Fake? How to Spot Them and What to Do
Yes, some App Store and Google Play reviews are fake — but fewer survive than you think. How to spot them, and what to do when they hit your app.
Read more