Is Spotify down? Measuring the revenue impact of app outages

Spotify experienced service problems on September 29, 2026. For someone searching “is Spotify down,” the immediate concern is whether music will play again. For an app founder, the next question is harder: how much revenue does an interruption actually put at risk?

There is no defensible universal cost per minute. An unavailable session, a delayed purchase and a canceled subscription have different financial consequences. This article reviews the incident using information checked on September 30, then offers a practical method for estimating exposure in your own app. It is an incident review, not a live status monitor.

What happened on September 29?

Tom’s Guide documented problems with Spotify’s mobile and desktop apps and embedded an acknowledgement from Spotify’s status account. Its reporters also encountered problems in the US and UK. The live report followed disruption over several hours; by its 18:10 UTC update, reports had fallen substantially and the publication considered service apparently restored. That update still noted the absence of an official all-clear. Read the incident coverage.

The acknowledgement is linked from the official Spotify Status post. We could verify its wording through the embedded reporting, but could not independently retrieve the post. We have not verified an official root-cause report, an exact worldwide recovery time or a financial loss figure for this incident.

Crowdsourced outage reports establish that people experienced problems; their count is not a count of unique affected customers, failed payments or lost subscriptions. Those measures require different evidence.

Why outage duration is not a revenue estimate

Start with the part of the product that failed. Could people open the app, play content, see ads, purchase a subscription or use an already-paid entitlement? Were all countries affected, or only certain platforms and versions?

Spotify’s own accounting illustrates why this distinction matters. Its 2025 annual report says Premium streaming revenue is recognized over the subscription period on a straight-line basis, while separately identifying service interruptions as a business risk. That is context about its business model, not a calculation of this outage’s losses. Spotify 2025 Form 20-F, revenue recognition and risk factors.

Dividing annual revenue by the number of minutes in a year and multiplying by downtime produces an allocation of average revenue. It does not show what the company lost. It ignores unaffected customers, subscription billing, delayed purchases, refunds and activity that returns later.

For your own app, separate the following questions before assigning a monetary value:

These are possible mechanisms to investigate, not claims that each occurred at Spotify.

Estimate advertising exposure with your own numbers

Google defines eCPM as earnings divided by impressions, multiplied by 1,000. That provides a useful starting point for an exposure estimate. Use displayed impressions, not ad requests or active users. AdMob’s eCPM definition.

Estimated advertising revenue at risk = missing impressions ÷ 1,000 × comparable baseline eCPM.

Here is a deliberately hypothetical example, unrelated to Spotify:

The arithmetic is 70,000 ÷ 1,000 × USD 4.00. The USD 280 is a scenario estimate, not a measured causal loss, a profit figure or an industry benchmark.

The baseline is the important assumption. Compare the same weekday and hours across recent unaffected weeks; exclude unusual campaigns and known incidents. Estimate separately for materially different countries and ad formats, using a consistent currency. If the plausible shortfall is 50,000–80,000 impressions and comparable eCPM is USD 3–5, a simple sensitivity range is USD 150–400. This is a range of assumptions, not a statistical confidence interval.

Revisit the estimate over a defined recovery window. Extra activity above the normal baseline may offset some shortfall, but do not subtract every post-recovery impression: most would have happened anyway. If prices or traffic mix change, reconcile the earnings difference separately from the impression-only estimate.

Our ad revenue calculator helps explore impression and eCPM assumptions. It does not detect outages or establish what would have happened without one. Use the AdMob earnings investigation guide when you need to distinguish delivery changes from pricing changes.

Measure subscription consequences over time

App availability and billing state are separate questions. Apple describes auto-renewing subscriptions as renewing at the end of their duration until canceled. Google Play documents renewals and payment recovery as subscription lifecycle events. An inaccessible app screen alone does not establish that a renewal failed. Apple subscription overview, Google Play subscription lifecycle.

For an incident review, examine three groups independently:

1. Potential new subscribers. Compare paywall access, checkout attempts and confirmed purchases. Follow delayed completions before counting the entire shortfall as lost sales.
2. Subscribers due to renew. Check verified renewal and payment-recovery records. Distinguish a payment decline from delayed reporting or failed entitlement delivery.
3. Existing subscribers exposed to the incident. Track refunds, cancellation requests and eventual expirations over the following billing cycles. A cancellation request is not necessarily an immediate loss of paid access.

Where your data supports it, compare affected users with a similar unaffected group and account for changes in pricing, acquisition and product releases. Without that evidence, describe a post-incident increase in cancellations as an association rather than a proven consequence.

Do not multiply every cancellation by an assumed lifetime value. Start with observed revenue or proceeds for a stated follow-up period. Keep refunds already reflected in that measure from being subtracted a second time. Likewise, RevenueCat and store reports can describe the same underlying purchases; they are not automatically additive revenue sources. Our combined revenue guide explains the reporting boundaries.

Make sure the apparent loss is not missing data

A reporting pipeline can fail alongside the app. A blank dashboard during an incident might mean that activity stopped, that telemetry stopped arriving, or both.

AdMob says its metrics commonly arrive with a delay and third-party waterfall data can take longer. Wait for the relevant reports before treating absent rows as zero. AdMob data freshness.

Use this sequence for a review:

1. Record the incident window, time zone, affected platforms and failed user actions from operational evidence.
2. Check source-report completeness and reconcile delayed transactions and events.
3. Compare advertising, new purchases and renewals separately against explicitly chosen baselines.
4. State the estimate, its assumptions and the unresolved data gaps together.
5. Recheck after the recovery window and relevant renewal dates, then choose one reliability improvement to validate.

If you have only daily provider totals, report a daily comparison. Do not present them as minute-level outage measurements. Monitoring logs and incident timing must come from your operational tools; revenue reports alone cannot identify the technical cause.

Choose the next action from the failed journey

A confirmed ad-serving interruption calls for checking ad load and display success after recovery. Failed purchases call for reconciling transactions and verifying that paid users receive access. A failure to open the app calls for testing the affected startup and authentication paths. These lead to different fixes and different success measures.

After the immediate repair, add the incident and follow-up dates to your weekly metrics review. Measure whether the failed journey stays healthy and whether revenue returns to its expected range. Keep the cost of support, compensation and engineering response separate from the revenue estimate when evaluating the broader business impact.

The September 29 Spotify disruption is a useful prompt to prepare this process. Public evidence supports that an incident happened. It does not support assigning Spotify a dollar loss or applying a fixed downtime percentage to every mobile app.