AdMob rewarded video defect on Android runs eight days with no workaround

A defect that stops AdMob rewarded ads from playing video on Android has been open for more than a week, and the mitigation Google deployed on 28 August 2026 still leaves some publishers without a working format. Google logged the incident at 21:19 UTC on Thursday 20 August 2026 and posted the first public note five minutes later, at 21:24 UTC. PPC Land, which tracked the dashboard record in its report on the incident, describes a symptom that is narrow and specific: rewarded ads fail to play video on Android applications and display a large play icon in place of the creative.

As of the most recent update, timestamped 17:16 UTC on Friday 28 August 2026, the incident remained open. That puts the elapsed duration at roughly 188 hours, or seven days and twenty hours, between the recorded start of the fault and the latest engineering note. Three status entries cover that window, and each one closes with the same line: there is currently no workaround.

What the dashboard actually recorded

The first entry, published at 21:24 UTC on 20 August, contained no diagnosis. Google stated it was investigating reports of an issue with AdMob and would provide more information shortly. Affected users retained access to the AdMob interface itself, the notice said, but encountered error messages, high latency and other unexpected behaviour.

A second entry followed at 01:10 UTC on Saturday 22 August, roughly twenty-eight hours later. The wording shifted. Service had already been restored for some users, according to the dashboard, and a resolution for all users was expected in the near future, with the caveat that the time frame was an estimate subject to change. On the underlying defect, the update said only that engineering was continuing to work on the mitigation.

Then the log went quiet for approximately 160 hours. The next entry did not arrive until 17:16 UTC on 28 August, and it carried the first substantive technical claim of the sequence. According to the Google Ads Status Dashboard, engineering had identified the root cause and deployed a mitigation covering most users, while work continued to address the remaining impact.

The phrase "most users" is doing a lot of work in that sentence. It concedes that a subset of AdMob publishers remained affected at the time of writing, without quantifying the share, naming the affected regions, identifying which app categories or SDK versions carried the fault, or offering any estimate of when the residual impact would clear. A publisher reading that entry cannot determine from it whether they are inside the fixed group or the remaining one. The only way to find out is to look at their own numbers.

The severity label is the part worth arguing with

Google's status dashboard uses four states: available, service information, service disruption, and service outage. All three entries in this incident carry the service information marker, which is the lowest of the three non-nominal tiers, sitting below service disruption in Google's own taxonomy.

This is a fair criticism to make because it rests entirely on Google's published categories rather than on any guess about intent. What the classification means, in practice, is that an eight-day failure of a revenue-generating ad format was never escalated past the mildest category the dashboard offers. Publishers who filter dashboard alerts by severity, and many operations teams do exactly that to avoid alert fatigue, would not have been paged. The label is not an accusation of bad faith. It is a statement about where this incident sat in a hierarchy Google itself defines, and about the gap between that position and the practical consequence for a publisher whose primary format stopped rendering.

The practical lesson is about your own monitoring rather than about Google's. If your alerting depends on a vendor's severity classification, the classification becomes your threshold. A format that stops earning is a revenue event in your own numbers regardless of which tier a dashboard assigns it, and your own numbers are the only trigger you fully control.

Why a rewarded video failure removes the product

Rewarded video is a transactional unit. A user consents to watch a complete video in exchange for an in-app benefit, and the publisher is paid on completion. When the video does not play and a static play icon appears instead, the transaction does not complete. No completion means no reward delivered to the user, and no impression monetised at the rate that made the placement worth building in the first place.

That is a different failure mode from an underperforming banner. A banner that earns less still earns. A rewarded unit that will not render earns nothing on that impression and also breaks the in-game economy the reward feeds, because the player who tapped to earn currency did not get the currency. For a mobile game publisher running rewarded video as the primary revenue stream, this is not a degraded experience, it is the removal of the product.

The format's weight has been growing. Singular's 2026 ROI Index described rewarded and incentive-driven environments as appearing prominently across gaming and growth leaderboards and no longer functioning as experimental budget lines, attributing the shift to stronger retention filtering, improved fraud controls and more disciplined optimisation. Magnite secured exclusive global rights to monetise Roblox's rewarded video inventory in January 2026, covering 151 million daily active users. Kantar research commissioned by AppLovin and published in February 2026 found that 71 percent of mobile gamers who bought a product after seeing a mobile game advertisement did so on the same day. Google itself introduced high-engagement settings for interstitial and rewarded units in February 2025 and added InMobi, ironSource and Unity to AdMob mediation in July 2025.

Why there was no workaround for eight days

The repeated declaration that no workaround exists is the operationally significant detail in the record. In most platform incidents a workaround gives affected parties something to do: a fallback endpoint, a rollback to a prior library version, a temporary configuration change. Its absence across all three entries means publishers had no documented remediation path for the full duration.

The structural reason is the SDK. In-app advertising is delivered through code compiled into the application binary, and the rendering behaviour of a rewarded unit is governed by the Google Mobile Ads SDK rather than by any setting a publisher can toggle in a web console. A publisher who identifies that rewarded video has stopped rendering cannot patch the rendering path without shipping a new app release, and a new app release cannot fix a defect whose root cause sits inside a dependency the publisher does not control.

That dependency is in transition. Google designated the rewritten Google Mobile Ads Next-Gen SDK as the preferred kit for Android on 6 July 2026, formally classifying the previous SDK as legacy and starting a deprecation clock that runs to a sunset date of 30 June 2028. The Next-Gen SDK entered beta on 22 January 2026, built in Kotlin, with Google citing banner ad requests completing up to 27 percent faster and a 17 percent reduction in device footprint. Nothing in the status dashboard entries identifies which SDK generation the rewarded video defect affects, or whether both are implicated. That is not an inference to be filled in. It is simply absent from the record.

The revenue line sitting behind the incident

AdMob sits inside Alphabet's Google Network segment, alongside AdSense and Google Ad Manager, and that segment has been contracting. Network revenue fell 4 percent year over year to 6.97 billion dollars in the first quarter of 2026, and slipped a further 1 percent to 7.3 billion dollars in the second quarter, reported on 22 July 2026.

No revenue-impact figure for this incident has been published, by Google or by anyone else, and none is estimated here. The segment numbers are context for where AdMob sits in Alphabet's reporting, not a basis for calculating what any publisher lost. Anyone quoting a loss figure for this incident is extrapolating, and an extrapolated number in a revenue-share conversation is worse than no number at all.

What this means for Thai marketers

If you publish an Android app or run a game studio in Thailand with rewarded video in the monetisation mix, there are four things worth doing while the defect has no workaround, and the first is measurement rather than action.

Measure the loss instead of guessing it. Pull rewarded impressions, completion rate and rewarded eCPM by day, and compare the window from 20 August 2026 forward against the equivalent period before that boundary. Segment by platform, because the reported symptom is specific to Android applications, and a comparison that mixes iOS in will understate the gap. Segment by app and by placement too, since the 28 August entry says most users rather than all users, and your own data is the only way to tell which side of that word you are on. If your analytics and measurement setup does not currently break rewarded completions out by platform, that reporting gap is the first thing to fix, because it is the gap that makes the next three steps guesswork.

Decide whether to reweight mediation temporarily. If rewarded is failing on Android and interstitial or banner formats are unaffected in your own numbers, shifting weight toward the formats that still render, or toward other networks in your mediation stack, recovers some of the yield. Treat this as a reversible experiment with a defined end, not a permanent restructure, because reweighting a waterfall has its own costs and the defect is expected to clear. Write down the date you changed it and the date you intend to change it back.

Document the window. If there is any revenue-share conversation to be had with a partner, publisher network or platform, the useful artefact is a dated record: when the format stopped performing in your data, what the delta was, what you did about it, and the dashboard timestamps that corroborate the incident. Build that file while the numbers are fresh. Reconstructing it in November from memory is a much weaker position.

Do not shift the whole plan on one incident. If rewarded inventory is a meaningful part of how you monetise, a temporary defect is a reason to diversify demand sources deliberately over the next quarter, not a reason to tear the stack apart this week. The same logic applies on the buying side: an advertiser running user acquisition through Google Ads app campaigns into Android inventory, or through TikTok advertising and paid social channels, should be checking whether their own install and post-install numbers moved across the same 20 August boundary before attributing a change to creative or bidding.

SDK dependency is a risk that account hygiene cannot touch

This incident is a clean illustration of a structural point that is easy to forget when the day job is optimisation. Almost everything a media or monetisation team does well, tightening targeting, cleaning up placements, improving creative, fixing tracking, operates on configuration. Configuration is the layer you control. An SDK defect sits underneath all of it, compiled into your binary, shipped by a vendor, and unreachable from any console.

No amount of account hygiene mitigates that. What does help is knowing which SDK versions are live across your app estate and having a release path you can execute quickly when a fix does land, so that the moment a vendor ships a patched library you are not waiting on a two-week release cycle to pick it up. Keeping an inventory of ad SDK versions per app build, with the dates each version went live, turns an incident like this from a mystery into a lookup.

What to watch on the dashboard

Three things are worth checking on the Google Ads Status Dashboard for this incident. Whether the status changes from open to resolved, since as of the 28 August entry it remained open. Whether any subsequent entry quantifies the remaining impact, names regions or app categories, or identifies the SDK generation, because none of the three entries so far do any of that. And whether the severity classification is ever revised above service information.

What the source does not say is also worth stating plainly. There is no root cause description beyond the statement that engineering identified one. There is no publisher count, no regional breakdown, no app category list, no SDK version identification, and no estimate of when residual impact clears. There is no published revenue impact. Those are gaps in the record, not questions with answers somewhere else.

Frequently asked questions

How long has the AdMob rewarded video defect been running?

Roughly 188 hours, or seven days and twenty hours, as of the most recent update. Google logged the incident at 21:19 UTC on 20 August 2026, and the latest entry was timestamped 17:16 UTC on 28 August 2026 with the incident still open.

What exactly is the symptom?

Rewarded ads fail to play video on Android applications and display a large play icon in place of the creative. That is the description on the Google Ads Status Dashboard, and it is specific to Android applications as recorded.

Is there a workaround?

No. All three status entries state that there is currently no workaround, and the structural reason is that rewarded rendering is governed by the Google Mobile Ads SDK compiled into the app binary rather than by a console setting a publisher can change.

Which SDK version is affected?

Not stated. Nothing in the dashboard entries identifies which SDK generation carries the defect or whether both the legacy kit and the Next-Gen SDK are implicated, even though Google designated the Next-Gen SDK as preferred for Android on 6 July 2026 with a legacy sunset date of 30 June 2028.

How severe is Google treating this?

All three entries carry the service information marker, the lowest of the three non-nominal tiers on a dashboard that uses available, service information, service disruption and service outage. Service information sits below service disruption in Google's own taxonomy.

If rewarded inventory or Android app campaigns matter to your numbers, the useful next step is a dated before-and-after read across the 20 August boundary rather than a guess. Relevant Audience can help set up the reporting that makes an incident like this measurable the first time it happens rather than the second.