Loading post…
IntercomDanny Fallon,Ryan SherlockExplainer
The safety of speed: How we ship code 180 times per day
Summary
Intercom describes how it averages 180 production ships per workday in January 2026 while targeting 99.8+% availability, with an average 12-minute merge-to-production cycle. The post focuses on its Ruby on Rails monolith, deployed to three data-hosting regions through independent pipelines, and frames small batches as a way to limit accumulated risk. An automated pipeline builds a deployable slug, runs parallel CI, verifies it in pre-production with boot, CI, and Datadog Synthetics gates, then performs a staggered rollout with process-level rolling restarts. Safety also depends on engineer ownership, feature flags, production testing on a single host, outcome-focused heartbeat metrics, and rapid automatic or manual rollbacks. Incident reviews then harden the system, supporting the conclusion that speed is used to keep changes small, feedback immediate, and recovery fast rather than to trade stability for velocity.
Context
The discussion centers on Intercom’s Ruby on Rails monolith, its core application and most frequently deployed system. It is deployed to three different data-hosting regions with independent pipelines, while other services and frontend applications use similar pipeline principles and safeguards.
Approach / What changed
The system combines an entirely automated delivery pipeline with human ownership at merge and deployment time. Code is built into a slug, tested in parallel, verified in pre-production, and rolled out through staggered deployment and process-level rolling restarts. Feature flags, production testing on a single host, heartbeat metrics, automatic or manual rollbacks, and incident reviews provide additional safeguards and recovery mechanisms.
Takeaways
The pipeline builds a deployable slug in about four minutes, runs CI in parallel, and uses pre-production gates including boot tests, CI results, and Datadog Synthetics before production promotion.
Feature flags separate deployment from release, allowing changes to be enabled for all customers, subsets, or nobody in under 60 seconds while supporting phased rollouts and beta features.
Heartbeat metrics measure customer outcomes such as comments created; a drop can trigger an automatic rollback to the release running 20 minutes earlier.
FAQ
Why does Intercom page an engineer after three rejected releases?
The failures occur before production, but a stalled pipeline causes changes to accumulate. Paging an engineer restores small, frequent deployments before the next release becomes a larger and riskier changeset.
How does a production rollout avoid downtime?
The deployment is staggered across the fleet, while processes restart individually. Each old process finishes current work and terminates gracefully before a new process replaces it, allowing most of the global fleet to update within six minutes without downtime.
What happens when customer outcomes degrade after a deployment?
Heartbeat metrics can detect a drop in real-world activity even when infrastructure dashboards appear healthy. A critical anomaly can trigger an automatic rollback, while engineers can initiate a manual rollback that locks the production pipeline for investigation.
Source and freshness
- Source
- intercom.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.