The Google killing field: a decade of buried services and what they teach us

There is a long tradition of internet writing about Google's habit of killing its own products. The community-maintained Killed by Google catalogue is at almost 300 entries. Wikipedia keeps a list of discontinued Google services. Every few months a new sunset notice triggers another round of grim jokes.

It is easy to make this a joke. It is more useful to make it a pattern. Once you can see the shape of how Google retires consumer products, you can apply that lens to anything — Microsoft, Meta, Amazon — and stop being surprised when something you depended on appears in the graveyard · Limited signals.

This is the first post in our Internet Graveyard series. We catalogue the dead, but the catalogue is only useful if you can read the warning signs.

The eight archetypes

Not every shutdown is the same. After cataloguing 30 dead services for the Internet Graveyard we kept seeing the same eight patterns. Spotting which archetype a product fits is the most useful diagnostic.

1. The Half-Hearted Pivot

A product launches with fanfare. The metrics underwhelm. Instead of investing or killing it, the company spends 18 months trying to pivot it into something else, dilutes the original use case, and then kills the pivoted version too.

Canonical example. Google+ (2011 – 2019). Launched as a Facebook competitor. Pivoted to a "stream of interests" play. Pivoted again to be the canonical Google identity layer. Killed after a data leak disclosure and Google's own admission that 90% of sessions lasted under five seconds.

How to spot it. The product's tagline changes more than once in a year. Internal blog posts use the word "evolution" without specifying what the evolution is from. Engineering effort is visibly redirected.

2. The Acquisition Absorber

Google buys a company for its talent or technology. The team is folded into a parent product. The acquired product itself is killed once its IP has been extracted.

Canonical examples. Mailbox (acquired by Dropbox, but the same pattern: bought 2013, shut 2016). Mailbox's swipe-to-archive UX migrated into Google Inbox; the original app was killed. Posterous (acquired by Twitter 2012, shut 2013) — talent went on to build Twitter's photo and longform features. FriendFeed (acquired by Facebook 2009, shut 2015) — much of modern Facebook News Feed traces back to ex-FriendFeed engineers.

How to spot it. The acquisition announcement mentions "team" before "product." The product roadmap stops within six months. Updates become security-only.

3. The Strategic Refocus

Leadership announces a new "strategic priority." Anything that doesn't fit the new strategy is given six to twelve months to wind down.

Canonical example. Google Reader (2005 – 2013). RSS readers did not fit the new social strategy. Google's own announcement was titled "A second spring of cleaning" — corporate language for we're rationalising the portfolio.

How to spot it. A blog post from leadership talks about focus, choices, "what we're going to do less of." When that paragraph appears, every product is on a list somewhere.

4. The Beloved-but-Niche

A product is critically adored, has a passionate user base, and never reaches the scale Google needs from a product to keep paying its hosting bill. Google quietly retires it and points users at a parent product that does most but not all of what was loved.

Canonical examples. iGoogle, Picasa, Inbox by Gmail, Mailbox (Dropbox-era), Pocket (Mozilla now, shut July 2025).

How to spot it. The product hasn't shipped a major feature in 18 months. The dedicated subreddit is alive but small. Power users keep saying "I wish more people knew about this."

5. The Failed Bet

A high-conviction strategic investment that doesn't work commercially. The shutdown is typically faster and more expensive than the others.

Canonical examples. Stadia (2019 – 2023) — Google refunded all hardware and game purchases. Quibi (2020 – 2020) — short-form streaming raised $1.75 billion and shut in six months. Google Wave (2009 – 2012) — real-time collaborative communication too far ahead of its time.

How to spot it. Refunds. The presence of refunds tells you the company is trying to manage a PR crisis. Companies that planned to wind down gracefully don't usually issue blanket refunds.

6. The Replaced-by-Sibling

A second product in the same family eclipses the first. The first is killed because supporting both is expensive and confusing.

Canonical examples. Allo killed when Messages (RCS) became the strategic direction. Google Buzz replaced by Google+. Picasa replaced by Google Photos. Hangouts unwound in favour of Meet + Chat. Google Talk replaced by Hangouts replaced by Meet/Chat.

How to spot it. Two products in the same company share a category. The company invests visibly more in one of them. The other goes into maintenance mode.

7. The Privacy Cleanup

A product is killed not because it's failing but because keeping it running creates regulatory exposure.

Canonical example. Klout shut on the day GDPR took effect (25 May 2018). Klout's entire business model — assigning a public "influence score" to every public profile — was hard to reconcile with explicit consent requirements.

How to spot it. Major regulation is on the calendar. The product's data model is hard to retrofit for consent. The shutdown announcement uses words like "evolving privacy landscape."

8. The Hardware-Tied Retirement

A cloud service whose only purpose is to support a specific device. When the device retires, the service follows, sometimes years later.

Canonical examples. Jamboard (the device retired March 2024, the app sunset September 2024). Chromecast Audio. Various smart-home services tied to discontinued speakers.

How to spot it. The service runs on a device that hasn't had a new model in several years.

The five warning signs

The archetypes are useful in retrospect. What you actually want is prediction. Across every shutdown we've catalogued, the same five signals reliably show up six to eighteen months before the announcement.

Signal 1 — Feature freeze

The product has stopped shipping new features. Bug fixes continue, but nothing user-facing has changed in two release cycles. This is the cheapest signal to track because it doesn't require any insider information.

Signal 2 — Leadership reorg

The product moves under a different VP or merges into a parent organisation. Roadmap ownership becomes ambiguous.

This signal is harder to track from outside, but it leaks. LinkedIn updates from product managers — "now working on X family" instead of "leading X" — are an early indicator.

Signal 3 — A "we're listening" blog post

Counter-intuitive. The product team publishes a blog post or community-AMA acknowledging user complaints and promising "to do better." This rarely produces the promised improvements. It is usually the last substantial communication before a quieter post six to twelve months later announcing the wind-down.

Pocket's June 2024 community post fits this pattern. So does the Google Stadia pricing change post of late 2022, three months before shutdown.

Signal 4 — API quota withdrawal

The product's developer API gets new rate limits, deprecates endpoints, or rolls out a "more focused" v2 that drops capabilities the v1 had. Once the developer ecosystem starts to atrophy, the product has lost one of its retention moats.

Google Reader's API was effectively private for several years before shutdown — third-party clients existed in spite of, not because of, Google's developer relations.

Signal 5 — Mysterious "premium" tiers

A free product introduces a paid tier without a clear value-add. The paid tier doesn't perform. Six months later the whole product is "consolidating" into a sibling that already had a viable business model.

This was Twitter's pattern with Posterous. It is increasingly Meta's pattern.

What this means for users

If you depend on a consumer product from a large platform company, treat it as a depreciating asset.

The single most useful habit is periodic export. If a product has a Takeout button, use it. If it doesn't, your replacement plan needs to start before the announcement, not after.

What this means for builders

The flipside is more interesting. If your service might end up in someone else's slide deck of cautionary tales — and at this point that's almost everyone — the most generous thing you can do is make your data and integrations portable from day one.

Three principles:

1. Publish a canonical export format. Markdown for content, JSON for relational data, ICS for calendars, MBOX for email. Whatever's appropriate. Not zips of HTML.
2. Maintain a non-breaking API surface for at least three years past any deprecation. This is more than most do. It is also the thing power users remember about you forever.
3. When you do sunset, give an unusually long notice and a clear migration path. Pocket's nine-month wind-down was painful but professional. Mozilla preserved trust by being clear about dates, export windows, and what was happening to the API.

Frequently asked

Why does Google specifically have this reputation when other companies also kill products?

Three reasons. (1) Scale — Google has shipped enormously more consumer products than Microsoft or Apple, so the absolute number of dead ones is higher. (2) Brand — Google's brand carries an implicit promise of "this will be supported," which makes each shutdown feel like a betrayal. (3) The Killed by Google site exists. The visibility of the catalogue feeds the perception. Microsoft has killed dozens of consumer products. There is no canonical Killed by Microsoft site.

Is there a way to tell if a service is "safe"?

Not really, but you can stack-rank risk. Things that score well: long history, healthy revenue tied directly to the product, dedicated team that isn't shared with a sibling product, mature API with multiple third-party clients, exportable data in canonical formats. Things that score badly: any product offered free of charge with no clear monetisation path, products in the same family as a strategically more important sibling, hardware-tied services with no new hardware in years.

What does StatusDetector do about this?

We maintain the Internet Graveyard — a curated archive of 30 dead services with shutdown dates, evidence, replacement products, and domain status. We also surface live shutdown announcements on the Shutdown Radar. If you want to confirm a service is still alive, the Website Down Checker and Domain Status Analyzer probe the live state.

The shutdowns we're watching now

A few sunsets are already on the calendar.

• Google Fitbit Web Challenges — scheduled for 30 June 2026. Step-count challenges and group competitions baked into Fitbit since 2014.
• GitHub Issue Projects (classic) — retiring 24 August 2026. The original kanban view inside GitHub repos.
• Google Jamboard app — partially retired in 2024 alongside the device; final pieces in 2025.

You can see the full live countdown on the Shutdown Radar.

The most useful frame: every service is somewhere on a curve from healthy to retired. Most live their entire life in "healthy." A surprising number end up further along than their users expect.