Make deletes the Google Chrome app on 31 August, and there is no replacement
This is not a migration notice. The app is being removed from every organisation, Make offers nothing to move to, and the scenarios that use it stop on the day - so the work is finding them and deciding what happens instead.
The notice, in Make's own words
Most deprecation notices are really migration notices: a thing is going away, here is the thing that replaces it, move by this date. This one is not that.
Before August 31, 2026, the Google Chrome app is hidden from the app catalog, so you can't add it to new scenarios. Existing scenarios that use the app continue to run without changes until the end of support date.
- Google Chrome app and browser extension deprecation on August 31, 2026, Make Help Center
Then the date arrives:
the Google Chrome app will be removed from all organizations and the Chrome browser extension from the Chrome Web Store. After this date, scenarios that use the Google Chrome app will stop working.
- Google Chrome app and browser extension deprecation on August 31, 2026, Make Help Center
And the sentence that makes this different from every other deprecation you have worked through:
Make doesn't offer a replacement module for this functionality.
- Google Chrome app and browser extension deprecation on August 31, 2026, Make Help Center
The instruction is correspondingly blunt: "If you use the Google Chrome app in a scenario, remove it before August 31, 2026, to avoid disruption."
Why the hiding is the dangerous part
Look again at what happens before the date. The app is hidden from the catalogue, and existing scenarios keep running normally. From the inside, nothing has changed. Your scenario runs today, ran yesterday, and will run tomorrow. The only visible difference is that you cannot add the module to something new - and nobody notices a module they were not about to add.
So the warning period, which exists to give you time, is also the period in which the automation looks healthiest. There is no error to investigate, no warning in the run history, no degraded behaviour to catch someone's eye. The scenario is fine until the morning it is deleted out from under it.
A deprecation you can see is a task. A deprecation that keeps working perfectly until the deadline is a trap with a calendar attached.
The other half nobody reads
The notice covers two things, and most people read only the first. The app goes from Make. The browser extension goes from the Chrome Web Store.
Those have different owners inside a company. The Make app is the automation team's problem. The extension sits in a browser on somebody's laptop - possibly somebody who has no idea a scenario depends on it, possibly on a machine that belongs to a person who left. When the extension disappears from the store, it is not only new installs that stop: the local half of a workflow that spanned a browser and a cloud scenario has no supported home any more.
If your setup was "a person clicks something in Chrome, the extension hands it to Make, Make does the rest", then both ends of that sentence are being removed on the same day.
Six days, and what to actually do
The deadline in this article is 31 August 2026, and it is days away rather than months. If you use this app, the useful order is: find the scenarios today, decide what replaces them this week, and treat rebuilding as work that starts now rather than after the break.
Find every scenario that uses it. The app being hidden from the catalogue does not hide it inside scenarios that already have it. You are looking for modules whose app is Google Chrome, across every scenario in every organisation and team you own - including the ones nobody has opened in a year, which is where the old browser-driven automations live.
Decide honestly what each one was for. Because there is no replacement, the question is not "what module goes in this slot" but "what was this automation actually doing?" In practice the Chrome app tends to sit in one of three roles:
- Reading data from a page that has no API. The honest replacement is an API if one has appeared since, a data feed, or a scraping service that you own and can maintain. Not another vendor's browser module that could be deprecated the same way.
- Triggering a scenario from the browser as a convenience - a person on a page, clicking to send it somewhere. This is often replaceable by something duller and sturdier: a webhook behind a bookmarklet, a shared form, an email address the scenario watches.
- Automating a click sequence in a web app that has no other interface. This is the expensive case, and worth saying plainly: it may not have a good replacement, and the right answer might be to stop doing it in software and change the process instead.
Do not wait for it to break to learn which of the three you have. After the 31st, the scenario will not run, and the module will be gone from it - so the record of what it did is degraded exactly when you need to reconstruct it.
What "stops working" means for the rest of the scenario
Worth being precise, because it changes how much collateral damage you should expect. The Chrome module is a step inside scenarios that usually do other things too - write to a sheet, notify a channel, update a CRM. When the module is removed from the organisation, those scenarios do not quietly skip the step. They fail at it.
That failure then meets Make's ordinary error handling, which is where a second problem waits for anyone who does not go looking: a scheduled scenario that errors repeatedly gets deactivated after a number of consecutive errors, while a webhook-triggered one goes off on the first - the same counter that treats a timeout as a warning and never counts it at all. So the visible symptom in September may not be "the Chrome step failed". It may be "this scenario is switched off", discovered by someone wondering why the sheet stopped updating.
- Scenario runs normally right up to the deadline, no warning inside Make
- On the day, the module vanishes and runs start failing
- Repeated failures deactivate the scenario; the loss shows up downstream, later
- Every Chrome-app scenario located while the modules are still visible
- Each one classified: has an API, replaceable with something duller, or needs a process change
- Rebuilt or deliberately retired on your schedule, with the old scenario kept for reference
What we would do next
- List every scenario containing a Google Chrome module, across all organisations and teams, before the module disappears from view
- Screenshot or export those scenarios now, so the configuration survives the removal
- Classify each by what it was really doing: page reading, browser-triggered start, or click automation
- Replace the first two with an API, a webhook or a form; for the third, decide whether the process itself should change
- Check who has the browser extension installed — that half of the workflow ends on the same day
- Watch for scenarios deactivating in early September: repeated errors switch them off, and the cause will be a step that no longer exists
The deadline is real, the removal is complete, and there is nothing to migrate to. That combination is rare, and it means the usual instinct - wait for the vendor's replacement path - is the one instinct guaranteed to fail here.
Sources
- Google Chrome app and browser extension deprecation on August 31, 2026 - Make Help Center, read 25 August 2026. The date, the app being hidden from the catalogue beforehand while existing scenarios keep running, the removal from all organizations and from the Chrome Web Store, the absence of a replacement module, and the instruction to remove the app before the date.
- Overview of error handling - Make Help Center, read 25 August 2026. The consecutive-error threshold that deactivates scheduled scenarios and the immediate deactivation of instantly triggered ones — which is what turns a failing step into a switched-off scenario.
Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.
Get my quote in 24hWritten by the Fixmation team.