Practice & Reference · Case Study · Real company

Etsy & Continuous Deployment

This is a real, named company's story, and it sticks to what Etsy's own engineers have said about it in public — mainly on Etsy's engineering blog, Code as Craft (codeascraft.com), plus conference talks given by Etsy staff. Three threads run through it, and all three are threads this course has already introduced in the abstract: a deploy tool built to make shipping to production a one-click, many-times-a-day habit rather than a rare event; a way of writing up what broke afterward that is widely credited with popularizing the term "blameless postmortem" in software engineering; and a metrics culture built on two small open-source tools, StatsD and Graphite, under the banner "measure anything, measure everything."

The starting point: a marketplace that decided shipping should be boring, not rare

☺ Like you're 10: Etsy is the online marketplace for handmade and vintage goods, and starting around 2010 its engineers began writing publicly, in detail, about deploying to production constantly instead of occasionally — and the rest of the industry noticed.

Etsy is an online marketplace for handmade, vintage, and craft goods, founded in Brooklyn in 2005 and taken public on NASDAQ (ticker ETSY) in April 2015. On its own it isn't a company most engineers would reach for as a technical case study — the interesting part isn't what Etsy sells, it's how openly its engineering organization wrote, from roughly 2010 onward, about the mechanics of shipping code. In a November 2010 Code as Craft post titled "Continuous Deployment at Etsy: A Litany of Words About Shipping Code," engineer Mike Brittain described a team that had moved from batching up releases to pushing to production as often as around 25 times a day. Over the following several years — across further blog posts and conference talks by Etsy engineers — the figure climbed further, with numbers in the 40-to-50-plus-deploys-a-day range showing up repeatedly in public talks as both the tooling and the practice matured. Treat the exact numbers the way you'd treat any self-reported figure: directionally true and consistently repeated, not an audited statistic with a fixed methodology.

What made this notable at the time wasn't the raw count. It was that Etsy was, by its own account, a normal e-commerce business with a normal amount of risk in getting it wrong — real money, real sellers, real checkout flow — choosing to ship more often rather than less, on the theory that smaller, more frequent changes were individually safer than large, rare ones. That's the same "throughput and stability move together" claim this course covers on measuring success: the DORA metrics, being lived out years before DORA's research had a name for it.

Deployinator: the button that let anyone ship their own code

☺ Like you're 10: Etsy built a web page with one big button on it — press it, and your own change goes live — so shipping code stopped being a special ceremony only a few people were trusted to run.

The tool that made dozens of daily deploys practical was one Etsy built in-house and later open-sourced, nicknamed Deployinator for the oversized "deploy" button sitting at the center of its interface. Etsy engineers described it across several Code as Craft posts and conference talks — including a widely-cited QCon talk by Etsy engineer Ross Snyder, "Deploying the Etsy Way" — as deliberately stripped down: click the button, watch the build stream past in a log window, done. The point wasn't clever engineering inside the tool itself; the point was who was allowed to press it. Deployinator put deploys directly in the hands of the engineer who wrote the change, instead of routing every release through a separate operations team working from a ticket queue — the same "you build it, you run it" shift this course covers on culture & collaboration, expressed as a literal UI decision rather than a policy memo.

Ship code your first day: onboarding as a trust-building exercise

☺ Like you're 10: New engineers at Etsy were, by multiple public accounts, expected to push a real change to the live site on their very first day — on purpose, so the scary part happened once, early, with help standing right there.

One detail from Etsy's engineering culture got repeated often enough in industry talks and retrospectives, including Gene Kim, Jez Humble, and Patrick Debois's The DevOps Handbook, that it's worth treating as one of Etsy's most-cited practices: new engineers were routinely expected to ship a small change to production on their first day or in their first week on the job, walked through the process by a teammate sitting next to them. The point was never the size of the change — a typo fix or a copy tweak was completely normal. The point was demystifying the deploy pipeline before a new hire ever had a reason to be afraid of it, so that "pushing to prod" stopped being a rite of passage reserved for senior engineers and became just something everyone here does, starting immediately.

Read against Deployinator, the onboarding practice and the tool are the same idea from two angles: the tool made deploying technically trivial, and the onboarding ritual made deploying psychologically trivial. A pipeline only a few trusted people are allowed to touch recreates exactly the wall-of-confusion dynamic this course opened with — a small priesthood on one side, everyone else filing tickets and waiting on the other.

Blameless postmortems: the post that gave the industry its vocabulary

☺ Like you're 10: After something breaks, Etsy's rule was to ask "what about our system let this happen" instead of "who screwed up" — and the engineer who wrote the essay explaining why is the same person most of the DevOps world now credits with popularizing that whole idea.

John Allspaw is a familiar name from earlier in this course: he co-presented the 2009 Velocity talk with Paul Hammond that gave DevOps its founding moment while both were still at Flickr — see what is DevOps and the Flickr case study. Around 2010, Allspaw moved to Etsy as its SVP of Technical Operations, and in 2012 he published a Code as Craft post titled "Blameless PostMortems and a Just Culture." That single post is cited across the industry — in Google's own Site Reliability Engineering book, in PagerDuty's and Atlassian's incident-response documentation, and in countless conference talks since — as one of the pieces of writing most responsible for turning "blameless postmortem" from an obscure idea into standard vocabulary for how software teams should talk about failure.

Allspaw's argument draws directly on "Just Culture" research from aviation and healthcare safety science — fields that learned, often the hard way, that punishing individuals for honest mistakes doesn't make a system safer, it just makes people stop reporting near-misses. Applied to a postmortem, the practice means the written account of an incident focuses entirely on causal, systemic questions — what monitoring didn't catch this, what safeguard was missing, what made the error easy to make — and deliberately avoids the sentence "and then X did Y, which caused the outage" framed around a person's name. Etsy's engineering culture backed this with more than a blog post: engineers involved in an incident were expected to write and present the detailed, factual timeline themselves, on the theory that the person closest to the mistake usually has the most complete and useful information about it — information that dries up fast the moment people learn that speaking up gets them blamed.

Measure anything, measure everything: StatsD and Graphite

☺ Like you're 10: Etsy stuck a "thermometer" into practically every part of its code — even silly, unimportant parts — because adding one was nearly free, and having a graph you didn't end up needing beats needing one you never built.

The third pillar of this story is a February 2011 Code as Craft post by Etsy engineer Ian Malpass, titled "Measure Anything, Measure Everything." It introduced StatsD, a small daemon Etsy built and open-sourced — conceptually descended from an earlier internal tool called Gas at Flickr — for collecting simple counters, timers, and gauges out of application code and flushing aggregated statistics, typically every ten seconds, over UDP to a backend. Etsy paired StatsD with Graphite, an open-source time-series storage and graphing system originally built by Chris Davis at Orbitz, to turn those flushed numbers into dashboards anyone at the company could pull up.

The engineering choice worth noticing is UDP: StatsD's client sends its metrics and moves on without waiting for an acknowledgment, so a slow or unreachable metrics backend can never add latency to the actual request a real user is waiting on, and a dropped packet just means one missed data point rather than a production incident. That single decision is why "add a metric" could be a one-line, essentially free change in application code, which is what made "measure everything" a realistic policy rather than an aspirational one. Malpass's post is explicit about the resulting philosophy: Etsy's engineers graphed things that were obviously important (page load times, checkout errors, search latency) right alongside things that were frankly a little silly, because the cost of a graph nobody ends up needing is tiny compared to the cost of needing a graph during an incident and discovering nobody ever built it.

What to steal for your own team

☺ Like you're 10: You don't need Etsy's scale to copy the habits — smaller batches, a write-up that hunts for causes instead of a culprit, and a graph for the thing you'll wish you'd measured the day it breaks.

• Make the deploy tool boring on purpose. Deployinator's whole design philosophy was "as simple as it can possibly be" — a log stream and a button. A deploy tool that requires expertise to operate safely is quietly gatekeeping who's allowed to ship, which recreates the wall of confusion this course opened with. See CI/CD pipelines for the automated-test gate that has to sit in front of a button this simple for it to stay safe.
• Put a real question, not a form, at the center of your postmortem. Allspaw's post gives you the actual sentence to borrow: focus on "what about our system allowed this," never "who did this." Practice the mechanics of running one on Drill — Run a Blameless Postmortem.
• Bias toward a metric being cheap to add, not toward it being important. StatsD's fire-and-forget UDP design is a specific technical decision that made "just add a graph" essentially free — the philosophy and the low-friction tooling are the same lesson, not two separate ones. See monitoring & observability for the modern equivalent of this stack.
• Let people ship on day one, on purpose. A new hire's first production change doesn't need to matter — it needs to happen early, with a teammate right there, so the deploy pipeline stops being a mystery reserved for veterans. Pair this with a real inner-loop and developer-experience investment, or the first deploy will just be slow and painful instead of confidence-building.

Honest caveats: what doesn't transfer

☺ Like you're 10: A web app you can update instantly isn't the same as a mobile app stuck waiting on app-store review, and "self-reported in a blog post" isn't the same as an audited number.

• Etsy's deploy target was a single, actively-tooled web application, not every kind of software. A large fraction of this story is about shipping changes to a web app that Etsy fully controlled end to end. A mobile app waiting on app-store review, embedded firmware, or a regulated system with mandatory external sign-off cannot copy "deploy 50 times a day" as a literal target no matter how good the internal tooling gets — the transferable idea is small, frequent, reversible changes wherever your release mechanism allows it, covered more generally on feature flags & progressive delivery.
• The numbers are self-reported, from blog posts and conference talks, not an audited methodology. "25 deploys a day" and later figures near 50 come from named Etsy engineers writing and speaking publicly, which is a real and credible source — but it's not the same as an independently measured statistic with a fixed definition of what counts as one "deploy." Treat the trend as real and the exact number as approximate.
• This story is now well over a decade old, and Etsy's own infrastructure has moved on. Etsy completed a migration off its own data centers onto Google Cloud Platform around 2018. The specific tools in this case study — Deployinator, StatsD paired directly with Graphite — reflect the early-2010s state of the art; the ideas behind them (a low-friction deploy path, cheap metrics, blameless write-ups) outlived the specific tools, which is exactly why this course also covers their modern equivalents rather than teaching Deployinator itself as current practice.
• Blameless culture is easy to say and genuinely hard to sustain. Nothing about writing "blameless" at the top of a postmortem template makes an organization generative in Westrum's sense (see culture & collaboration) — it requires leadership that visibly doesn't punish the people who speak up, sustained over years, or the practice quietly reverts to blame with better paperwork.

Where this connects in the course

☺ Like you're 10: This one company's story touches four different lessons — read whichever matches what you're building next.

The deploy-tooling half of this story is the lived history behind CI/CD pipelines and the DevOps toolchain — Deployinator is a direct ancestor of every "click to ship" pipeline stage covered there. The blameless-postmortem half is the real-world source for the mechanics taught on culture & collaboration and incident management, and for hands-on practice, Drill — Run a Blameless Postmortem. The measure-everything half connects straight to monitoring & observability and to how those numbers eventually get formalized into a scorecard on measuring success: the DORA metrics. And John Allspaw himself is the throughline back to where this course started: what is DevOps and the Flickr case study cover the 2009 Velocity talk he gave before he ever got to Etsy. For other real-company stories sitting alongside this one, see Amazon & "You Build It, You Run It" and Google & the Birth of Error Budgets.

Check your answers

1. Deployinator was a simple one-click web tool that let any engineer push their own code straight to production, without routing through a separate operations team. The page argues it was a trust mechanism because the button itself added no safety — it only worked because it sat downstream of an automated test gate and upstream of dashboards that surfaced problems within minutes.
2. John Allspaw, who had previously co-presented Flickr's 2009 "10+ Deploys Per Day" Velocity talk with Paul Hammond before moving to Etsy as SVP of Technical Operations. "Just Culture" draws on safety research from aviation and healthcare.
3. Blameless means the write-up focuses on systemic causes — what monitoring, review step, or safeguard was missing — rather than naming an individual as the cause. It explicitly does not mean consequence-free or "nobody is accountable"; it separates "what happened and why" from "who's to blame" because mixing them makes people hide information.
4. StatsD and Graphite. StatsD sent metrics over UDP, a fire-and-forget protocol that never makes the application wait for an acknowledgment, so adding a new metric couldn't add latency risk to a real request — which is what made graphing something trivial essentially free.
5. The deploy-frequency figures come from Etsy engineers' own blog posts and conference talks over several years, not from one audited source with a fixed definition of what counts as a single "deploy" — directionally credible, but not independently verified.