The Outage Playbook: Replying to Reviews While Your App Is Down

The moment your API starts throwing 500s, the reviews start throwing 1-stars. Not because your app is bad, but because a person opened it, watched a spinner forever, and had no way to tell whether the problem was them, their phone, or you. So they did the one thing the store makes easy: rated you one star and typed "doesn't work." During an outage those reviews don't trickle, they pile, and they land on the worst possible day for your rating.

Here's the playbook. Catch the spike within minutes, not the next morning. Triage so the most-read reviews get answered first. Reply with an apology that's templated for speed but specific enough to sound like a human who knows what broke. Then, once you're back up, go update those replies, because "we're on it" ages badly when the issue was fixed three hours ago. An outage is temporary; the reviews it leaves behind are permanent unless you work them.

A working app is invisible. A broken one is a wall the user walks straight into, and the review box is right there on the way out. Two things make an outage uniquely dangerous. First, the reviews cluster: instead of the usual handful a day, dozens land in an hour, almost all 1-star, almost all some variation of "won't load." Second, store ratings are recency-weighted (Google confirmed this at Google I/O 2019), so a fresh cluster of 1-stars pulls your visible average down harder than the same reviews spread over a month.

The reviewer isn't wrong, exactly. From where they sit the app is broken, and a 1-star is a fair reaction to a spinner that never resolves. That's why you can't fight these the way you'd fight spam or a [coordinated review bomb](/blog/app-review-bombing-survival-guide), where the play is to report policy violations and out-wait the brigade. Outage reviews are legitimate. Your job isn't to get them removed, it's to answer them so well that they read, in hindsight, as evidence you were on top of it.

Most teams learn about the review damage the way they learn about most bad news: someone screenshots it in Slack the next morning. By then the cluster is a day old, unanswered, and your average has already slipped. The fix is to treat a review-velocity spike as its own alarm, separate from uptime monitoring. Your status page says the servers are down; your review feed shows how users are reacting in real time, and sometimes it fires first, because a user hits the bug on a code path your synthetic monitoring doesn't cover. Watch for the tell-tale shape of an outage in your reviews:

This is where monitoring pays for itself. ReplyArgus watches your App Store and Google Play reviews in one inbox and pings you on Slack, Discord, Telegram, webhook, or email the moment new low-star reviews land, so an outage cluster shows up in front of the on-call engineer within minutes instead of during standup tomorrow. If you don't have alerting wired up yet, our guide on how to [get notified of new App Store reviews](/blog/get-notified-of-new-app-store-reviews) walks through the options. The faster you see the wave, the more of it you can still be replying to while it's cresting.

You will not out-type an outage in real time, and you shouldn't try. So triage instead of firefighting blind. The reviews that matter most are the ones future prospects will actually read, and the ones from users who are one good reply away from staying.

The outage reply has a specific job, and it's not to grovel. It's to convert a frustrated 1-star into a reader who thinks "okay, they know, it's being fixed, I'll wait." That takes three things: honest acknowledgment that it's broken, a concrete signal that you know what broke and are fixing it, and a low-friction path to help. The trap is sounding like a form letter. "We apologize for any inconvenience" is what an insurance company says. Name the actual symptom the user hit and you sound like the engineer staring at the same dashboard they are.

Templated and specific aren't opposites. Keep a skeleton ready so you're not composing from scratch under pressure, then drop in the real detail: what failed, that it's a known issue, and a rough when. "Known issue, fix rolling out" beats vague reassurance because it tells the reader you've diagnosed it. Just don't promise a timeline you can't hit; an ETA that slips to tomorrow is worse than no ETA. Here's the shape during the incident:

This is the move that separates a team that handled an outage from a team that just survived one. Both stores let you edit a developer reply after you've posted it. So the "we're on it, fix incoming" reply you left at 9am should not still be sitting there at 3pm saying "fix incoming" when the fix shipped hours ago. Go back through the list you kept in triage and update each one to close the loop: it's fixed, here's the version, thanks for hanging in.

Why bother, when the user has probably moved on? Because the reply isn't for that one user anymore, it's for every prospect who reads your reviews next week. A 1-star with a stale "we're working on it" underneath reads like a company that dropped the ball. The same 1-star with "fixed in version 4.2.1 that afternoon, sorry for the disruption" reads like a company that's reliable when things break, and it gives the original reviewer a reason to come back and raise their stars, which is the thing that actually repairs your average.

Doing this by hand across two stores, in every language your users write in, while your engineers are heads-down on the actual fire, is a lot. This is the seam where ReplyArgus fits: it drafts the acknowledgment grounded in your past approved replies so it sounds like you, translates it into the reviewer's own language, and lets you edit and re-post the resolved version in a couple of clicks once you're back. It's approve-by-default, so nothing goes out that you didn't sign off on.

Recency weighting, the thing that made the outage hurt, is also what heals it. Because both stores lean on recent reviews, every honest new review you earn after the incident pushes the outage cluster further into the past and dilutes its weight. The fastest legitimate recovery is to get your normal, happy users rating again. That's a review-velocity problem, and we've written the full playbook on [how to raise review velocity without begging](/blog/review-velocity). Prompt for reviews at a genuine win in-app, never right after a crash, and keep the momentum for a few weeks past the incident.

Replying does real work here too, and [there's data behind it](/blog/does-replying-to-app-reviews-raise-your-rating). Hassan et al., studying 4.5 million reviews, found users who received a response were roughly 6× more likely to raise their rating (4.4% versus 0.7%), and Google reported an average lift of about +0.7 stars when developers respond. That's exactly why updating your outage replies matters: a resolved-and-apologized reply is an open invitation for that user to bump you from one star back to four. It also helps that [recent reviews weigh more](/blog/recent-reviews-weigh-more) than old ones, so the recovery reviews you earn this week count for more than the outage 1-stars will next month.

An outage is judged not by the fact that it happened, because everyone's app goes down eventually, but by how visibly you handled it in public. Catch the spike in minutes, triage to the reviews that get read, reply with a specific apology, and close the loop once you're back. If you'd rather not babysit two review feeds waiting for the flood, let Argus watch them for you: one inbox, instant low-star alerts, and drafted replies in 100+ languages you can edit and update in a couple of clicks. [Start free, no card, and Argus drafts your first outage reply in minutes](/signup). The full alerting and monitoring setup lives on the [features page](/features).