Werner Vogels' "You Build It, You Run It" Explained

What "You Build It, You Run It" actually means

"You Build It, You Run It" means the team that creates a service remains accountable for its behavior in production. Design, delivery, reliability, support, and operational improvement belong to one continuous job instead of passing through disconnected departments.

A team working this way does more than write code and complete a deployment. It watches production signals, responds to failures, controls operational risk, and decides when reliability work should take priority over feature work. Direct exposure to production creates a short feedback loop: poor alerts, fragile releases, and confusing recovery procedures become problems the builders have reason and authority to fix.

Shipping and operating are one responsibility

The operating model joins activities that traditional organizations often separate. A service team normally owns five areas:

• Designing, testing, deploying, and maintaining the service
• Monitoring user-facing reliability, performance, and capacity
• Responding to incidents and communicating their impact
• Managing security findings, dependencies, and operational cost
• Improving code, automation, documentation, and recovery procedures

This does not require every developer to become a network, database, and infrastructure specialist. It requires enough operational knowledge to diagnose the team's software, supported by platform specialists and documented escalation paths when deeper expertise is needed.

Authority must match accountability

A team cannot run a service responsibly without production visibility, safe controls, and time to act. If leaders assign pager duty but deny access to logs, deployment controls, capacity settings, or roadmap space, they have transferred stress rather than ownership.

Real accountability includes the authority to pause a release, disable a faulty feature, roll back a version, request help, and schedule work that prevents another incident. It also requires a clear budget for maintenance. Reliability cannot survive indefinitely as spare-time work behind a full feature plan.

Accountability is not blame

Accountability means owning the response and the improvement, not finding an individual to punish. Most serious failures involve several conditions: a risky assumption, weak test coverage, a missing limit, an alert that fired too late, or a recovery step that nobody had practiced.

A blame-driven culture hides information because people protect themselves. A learning culture rewards early escalation and precise reporting. The question after a failure is not who made the final change. It is why the engineering system allowed one change to cause that amount of customer harm.

Where the philosophy came from

Werner Vogels, Amazon's chief technology officer, popularized the phrase while explaining Amazon's service ownership model. The idea described software as a continuously operated service, not a project that developers finish and transfer to another department.

The phrase became memorable because it condensed an organizational change into six words. Teams responsible for production would make different design decisions. They would care about useful telemetry, predictable failure behavior, controlled deployments, and recovery paths before customers exposed those omissions.

The service mindset behind the phrase

A service mindset measures success through production outcomes rather than release completion. Passing tests and deploying successfully matter, but neither proves that users can complete their work at the expected speed and reliability.

This distinction became more visible as internet services moved toward continuous delivery and round-the-clock use. Large release events left too much time between a code change and feedback. Smaller releases, stable team ownership, and direct production signals made failures easier to isolate and lessons easier to apply.

Its relationship to DevOps

"You Build It, You Run It" is compatible with DevOps, but the terms are not interchangeable. DevOps covers a wider set of cultural and technical practices intended to reduce friction between development and operations. The Vogels formulation makes one specific commitment: the builders retain responsibility after deployment.

An organization can automate its delivery pipeline and still preserve a hard production handoff. It can also use a central operations group while giving product teams meaningful responsibility for diagnosis, remediation, and long-term service health. The deciding factor is where accountability and decision authority sit, not which department names appear on an organization chart.

Why service ownership changes delivery

Service ownership improves delivery by placing production evidence in the same team that makes design and priority decisions. Engineers see the operational cost of their choices while the reasoning behind those choices is still fresh.

Under a relay model, developers may hear about a slow service through a ticket several days after release. Logs may have expired, the deployment context may be missing, and the operations team may know the symptom without knowing the code path. Each handoff removes information and adds waiting time.

Direct ownership changes the incentives. A team repeatedly awakened by a noisy alert has reason to fix the alert or remove its cause. A team that must recover a failed deployment has reason to make rollback safer. A team paying the infrastructure bill has reason to examine wasteful queries and excessive resource requests.

Faster delivery comes from smaller risk

Teams can release more frequently when each release is easy to observe, limit, and reverse. Small changes narrow the diagnostic search space. Canary deployments and feature controls restrict exposure. Automated recovery steps reduce the time between detecting a regression and restoring service.

Speed here is not the absence of controls. It comes from making controls repeatable and inexpensive. A manual approval meeting may slow every release without detecting subtle production failures. Automated tests, policy checks, staged exposure, and live service indicators provide evidence at the point where it can change the outcome.

Repeat incidents become planning evidence

Recurring failures reveal work the team must place on its plan. Page volume, error-budget consumption, recovery time, and repeated manual interventions show where operational debt is accumulating.

This feedback only works when teams can act on it. If every sprint is filled before incidents occur, the organization has decided that prevention has no capacity. The pager then records problems without helping the system improve.

What teams own in production

A service-owning team is responsible for defined outcomes across the service's life, including behavior that depends on other systems. Ownership does not mean controlling every dependency. It means understanding those dependencies, setting expectations, detecting their effects, and escalating through agreed channels.

Reliability and performance

Reliability ownership begins with the user journey. A process can be running while customers receive errors, wait too long, or see stale data. Teams should therefore measure successful outcomes rather than treating host health as proof that the service works.

Performance has the same user focus. Average latency can hide a slow minority of requests, so teams often examine percentiles and separate important operations. A checkout, search, login, or data export may need its own indicator because an aggregate service number can conceal its failure.

Cost, security, and data

Operational ownership includes controlling resource use, responding to security findings, and protecting data throughout its life. A service that meets its latency target by consuming an uncontrolled amount of compute is not operating well. Neither is one that restores quickly but loses accepted writes.

The team should understand its main cost drivers, secrets and access model, backup policy, retention obligations, and recovery objectives. Specialists can provide controls and review, while the service team remains responsible for using those controls correctly.

Support and product behavior

Customer support is part of the production feedback loop. Support staff often detect confusing states, partial failures, and misleading error messages before automated monitoring does. Service owners need a clear way to receive these reports, assess severity, and provide useful status information.

Owning support does not require developers to answer every customer conversation. It requires a working connection between support and engineering, with enough diagnostic detail to identify the affected operation, time, account context, and visible symptom.

A named team and a defined boundary

Every production service needs one named owning team, even when several teams contribute code. Its record should state what the service does, which user journeys it supports, what data it holds, its dependencies, its reliability target, and how to reach the current responder.

Shared responsibility can exist at component boundaries. Ambiguity cannot. During an incident, people need to know who can decide, who can deploy, and which team owns each dependency. "Everyone owns it" usually means nobody has final authority.

On-call without burnout

A healthy on-call system pages the right people for urgent, actionable customer impact and gives them enough support to recover safely. It is not a test of endurance or a way to extract unpaid capacity from a small team.

Design the rotation around sustainable coverage

Rotation size determines how often each person carries the pager and how much recovery time the team can offer. A service with continuous coverage needs enough trained responders to handle leave, illness, and simultaneous incidents. When staffing cannot support that model, leaders should reduce service scope, use business-hours coverage with an escalation agreement, or arrange a shared secondary rotation.

A workable policy defines:

• Primary and secondary responders, with clear handoff times
• Severity thresholds and expected acknowledgement times
• Escalation contacts for platform, security, data, and management
• Compensation or time recovery after disruptive calls
• Training, shadow shifts, and periodic response exercises

No responder should face an unfamiliar high-impact failure alone. A secondary can help investigate, communicate, or bring in the correct domain specialist while the primary concentrates on mitigation.

Page only for action that cannot wait

A page should indicate a condition that threatens users or data and requires immediate human action. If waiting until the next working period will not change the outcome, the signal belongs in a ticket or scheduled review.

A simple severity model can separate full outages, material degradation, and non-urgent defects. Severity should account for affected users, duration, data risk, security exposure, and available workarounds. A small error-rate increase may deserve an immediate page for a payment path but only a ticket for an internal report.

Every page needs an owner, a useful summary, relevant context, and a first response. Alerts based only on CPU or memory often lack that connection. Alerts tied to failed requests, delayed jobs, or exhausted reliability budgets give responders a clearer reason to act.

Treat page volume as engineering data

The desired trend is fewer unnecessary pages and faster handling of the necessary ones. Teams should review page frequency, after-hours disruption, false positives, repeated causes, and time spent on manual recovery.

A noisy alert should be corrected, downgraded, or removed. A repeated manual mitigation should become automation or a system change. If page volume remains high, the rotation is reporting a product and engineering problem, not a resilience problem in the people carrying it.

SLOs, SLIs, SLAs, and error budgets

Service-level indicators and objectives turn reliability into a measurable product decision. They let teams discuss whether a service is reliable enough without relying on impressions or demanding perfection everywhere.

The terms have different jobs

An SLI is a measured result, such as the proportion of successful requests or jobs completed before a deadline. An SLO is the internal target for that result over a defined period. An SLA is an external commitment that may specify remedies when performance falls below a contractual threshold.

A useful SLI describes an event users care about and defines which events count as good. Examples include successful requests below a latency limit, valid searches returning results, or scheduled exports completing by the promised time. Host uptime is weaker when a host can remain available while the user operation fails.

Choose targets from user needs

An SLO should follow the consequences of failure and the reliability of surrounding dependencies. Setting every service to 99.999% creates cost and complexity without proving that users benefit. A business-hours administration tool and a payment authorization service should not inherit the same target by default.

The measurement window matters. A 99.9% monthly availability objective permits 0.1% unsuccessful time, which equals 43 minutes and 12 seconds in a 30-day month when availability is modeled through time. Request-based objectives calculate the budget from eligible events instead. Teams should document the method so a percentage cannot hide conflicting interpretations.

Useful objectives specify:

• The user-facing event and what qualifies as successful
• Included and excluded traffic, with justified exclusions
• The target percentage and measurement window
• The source of measurement and handling of missing data
• The action policy when consumption becomes too fast

Error budgets connect reliability to planning

An error budget is the permitted amount of unsuccessful service within an SLO window. It is not a quota to waste. It is a decision tool that indicates how much delivery risk the service can currently absorb.

A team comfortably inside its budget can continue planned releases while watching normal safeguards. Rapid consumption should trigger narrower rollouts, dependency work, capacity changes, or a temporary shift toward reliability. Exhausting the budget may justify pausing risky releases until the service returns to a controlled state.

Burn rate is more useful than waiting for the final monthly result. It shows how quickly the budget is being consumed and can detect a severe short incident or a slower persistent degradation. Paging policies can combine short and long observation windows so teams respond quickly without waking people for brief measurement noise.

Production readiness and safer releases

Production readiness means a service can be observed, recovered, secured, and supported before it accepts real user traffic. A feature is not ready merely because its normal path works in a test environment.

Establish the operating minimum

The exact checklist depends on risk, but every service should answer the same practical questions. Who owns it? How will the team know users are affected? What can a responder do first? How is data recovered? How can a bad release be stopped?

A concise readiness review should cover:

• Dashboards and alerts tied to user-facing behavior
• Runbooks for common failures and escalation conditions
• Backup restoration tests, retention rules, and recovery objectives
• Capacity assumptions, resource limits, and dependency behavior
• Deployment controls, rollback procedures, and access restrictions

A checklist should record evidence rather than invite automatic approval. "Backups enabled" is weaker than the date and result of the latest restoration exercise. "Rollback available" is weaker than a rehearsed procedure with a known duration and a plan for incompatible data changes.

Limit exposure during deployment

Progressive delivery reduces the number of users affected while a new version proves itself. A canary release sends a controlled portion of traffic to the change and compares relevant indicators with the previous version. Feature controls can separate code deployment from user exposure and allow a faulty path to be disabled without replacing the entire release.

These methods need exit conditions. Teams should define which measurements permit expansion, which require a pause, and which cause an automatic or manual reversal. Feature controls also need owners and removal dates because abandoned controls create combinations that become difficult to test.

Rollback is not always safe. A release may include a database migration, message-format change, or external side effect that an older version cannot understand. In those cases, teams need compatible staged migrations or a tested roll-forward procedure. The recovery design belongs in the release plan, not in the incident chat after failure.

Test capacity and failure behavior

Load testing checks whether capacity assumptions survive realistic traffic, data size, and concurrency. Useful tests model the operations that consume scarce resources instead of sending an easy request at an arbitrary rate.

Failure testing examines dependency timeouts, unavailable instances, dropped connections, expired credentials, full queues, and partial network failure. The purpose is to confirm that the service fails in a controlled way, preserves data rules, and produces the signals responders need. Testing a failure without checking alert behavior and recovery leaves half the question unanswered.

Incident response and postmortems

Effective incident response restores service quickly through defined roles, controlled mitigation, and regular communication. Deep diagnosis can continue after user impact has stopped.

Use a repeatable response flow

The first responder confirms the signal, determines the likely scope, and assigns severity. A significant incident should have an incident lead who coordinates decisions, a technical lead who directs investigation, and a communications owner who sends consistent updates. Smaller teams may combine roles, but the responsibilities should remain visible.

A practical flow has five stages:

• Detect and validate the customer or data impact
• Assign severity, roles, communication cadence, and a shared timeline
• Mitigate through rollback, feature control, scaling, isolation, or traffic limits
• Verify recovery through user-facing indicators rather than component status alone
• Preserve evidence and schedule the learning review

Mitigation should favor the lowest-risk action that restores service. Responders do not need a complete causal explanation before disabling a new feature or returning to a known compatible version. They do need to record decisions and observations so later analysis is based on evidence.

Communicate useful facts

Incident updates should state what users experience, which functions are affected, what the team is doing, and when another update will arrive. Speculation creates confusion, while silence causes support teams and customers to invent their own explanations.

Internal communication needs the same discipline. A single incident channel or record should contain decisions, timestamps, links to operational evidence within the organization's systems, and role assignments. Parallel conversations can occur, but material findings should return to the shared timeline.

Write postmortems for prevention

A blameless postmortem documents customer impact, detection, the event sequence, contributing conditions, recovery, and follow-up work. Blameless does not mean vague. It means examining why an action made sense with the information and controls available at that moment.

The analysis should go beyond a final trigger. If a deployment caused an outage, the useful questions include why tests missed the behavior, why exposure expanded, why detection took that long, and why recovery required the steps it did. "Human error" stops the analysis before it reaches conditions the organization can change.

Each action item needs an owner, a due date, and a verifiable result. Work may include a regression test, a deployment guard, a clearer limit, an alert adjustment, automation, or a runbook correction. Teams should review overdue items and close them only when the preventive change is operating.

Tooling that supports service ownership

Service owners need tools that let them see user impact, trace behavior across dependencies, control releases, and retain incident work. Tools reduce investigation and recovery time, but they cannot decide who owns an outcome.

Observability should answer operational questions

Logs explain discrete events, metrics show behavior over time, and traces connect work across service boundaries. Together they should answer whether users are affected, where delay or failure begins, what changed, and whether mitigation is working.

Centralized structured logs are easier to search and correlate than free-form text spread across machines. Metrics should cover latency, traffic, errors, and saturation alongside product outcomes such as completed transactions. Distributed traces are especially useful when one request crosses several independently deployed services.

Retention must match investigation needs and privacy rules. Keeping every event forever creates cost and data exposure. Keeping too little can erase the evidence needed for a slow or late-reported failure. Teams should define retention by data type and remove secrets or sensitive fields before telemetry leaves the application.

Ownership metadata must stay current

A service catalog or developer portal can record the owning team, responder schedule, dependencies, dashboards, runbooks, source location, and reliability objectives. The value comes from accuracy, not the size of the catalog.

Ownership metadata should be part of service creation and team transfer workflows. A service should not enter production without an owner, and a reorganization should update operational records before the previous team disappears. Automated checks can detect missing fields, while people remain responsible for validating the boundary.

Automation should remove repeated manual risk

Standard deployment pipelines, telemetry defaults, incident templates, and recovery actions reduce variation between teams. Automation deserves the same review and testing as application code because a faulty recovery script or broad deployment permission can increase the impact of an incident.

Teams should retain an understandable manual path for situations where automation fails. The goal is controlled operation, not dependence on a button nobody can explain.

The role of platform teams

Platform teams make service ownership practical by supplying shared capabilities and safe defaults while product teams remain responsible for product-service outcomes. The platform is itself a product with users, reliability goals, support expectations, and an owning team.

Provide a paved path with escape routes

A paved path can include service templates, delivery pipelines, identity controls, secrets management, runtime configuration, health checks, telemetry, and approved deployment patterns. These defaults reduce the amount of specialized setup each product team must invent.

Adoption rises when the path is easier than a custom solution and when teams can see its constraints. Exceptions will exist for unusual workloads. A documented exception process should evaluate risk and support needs without forcing every service into a design that does not fit.

Guardrails should block known dangerous states, such as exposed secrets or deployment without an owner, while giving teams fast feedback. A ticket queue for every routine change moves the old handoff into a new department and weakens direct responsibility.

Separate shared services from product ownership

A platform team may operate authentication infrastructure, an orchestration environment, an artifact registry, or an observability system. Product teams still own how their applications use those services, including timeouts, fallback behavior, permissions, and user-visible failure.

The platform team owns the availability and support of the shared capability. The consuming team owns its integration and the promises made through its product. Both teams need compatible SLOs and escalation paths where a shared failure can affect several services at once.

Measure whether the platform reduces work

A platform should reduce setup time, deployment effort, operational variation, and avoidable incidents. Adoption alone is incomplete evidence because teams may be required to use a platform that creates substantial friction.

Useful feedback includes the time to create a production-ready service, failed deployment causes, support demand, upgrade effort, and developer satisfaction with common tasks. Platform teams can use these results as product input rather than assuming more features automatically improve ownership.

Managed services, serverless systems, and AI-generated code

Using managed infrastructure or generated code changes the operational boundary, but it does not remove responsibility for the application. A provider may operate hardware and runtime components while the product team still owns configuration, data, integration behavior, and the user promise.

Managed does not mean failure-free

A managed database can experience regional disruption, quota limits, slow queries, connection exhaustion, or incompatible maintenance behavior. The service team must understand what the provider guarantees, which controls remain available, and how the application behaves when the dependency slows or becomes unavailable.

Serverless systems remove some server-management tasks but introduce other concerns, including concurrency limits, cold starts, event retries, execution time limits, and cost tied to invocation patterns. Relevant indicators and runbooks should reflect that model instead of copying a host-based checklist.

Third-party APIs require similar treatment. Teams need timeouts, retry limits, circuit behavior, dependency monitoring, and a decision about degraded operation. Unlimited retries can turn one dependency problem into resource exhaustion across the application.

Generated software still needs an owner

AI-assisted and vibe-coding tools can shorten the path from an idea to working software, but production responsibility remains with the person or team shipping the result. Generated code must meet the same expectations for review, tests, access control, observability, data handling, and recovery.

Planning is especially valuable before generation because vague boundaries can produce software that works in a demonstration but is difficult to operate. Define users, data ownership, dependencies, failure behavior, deployment model, and service objectives before treating the application as production-ready.

Source access also matters. Teams need a practical way to inspect behavior, correct defects, review dependencies, and continue operating if a tool or model changes. Convenience during creation should not leave the production owner without the controls required to run the application.

Common failure modes and sensible adaptations

The model fails when organizations assign operational duties without changing staffing, authority, architecture, or planning. The slogan then becomes a justification for pager load rather than a system for learning.

Failure patterns to correct

Several patterns deserve immediate attention:

• Developers carry on-call but cannot schedule permanent fixes
• Service ownership is split across teams with no final decision maker
• Alerts report symptoms that responders cannot act upon
• Shared dependencies create failures that consuming teams cannot influence
• Firefighting receives recognition while prevention remains invisible

The remedy depends on the condition. Leaders may reserve capacity, clarify ownership, tune alerts, define shared-service agreements, or fund platform work. Adding another responder to a broken rotation spreads the harm without reducing its cause.

Regulated environments

Separation of duties, audited access, formal approvals, and controlled production changes can coexist with service ownership. The product team can remain accountable for reliability outcomes while executing changes through reviewed procedures and approved roles.

Useful adaptations include pre-approved incident actions, recorded emergency access, peer authorization for sensitive operations, and rehearsed escalation to an authorized operator. Compliance should define controls and evidence. It should not create uncertainty about who diagnoses the service or owns corrective work.

Legacy monoliths

A tightly coupled monolith may not support clean ownership by technical component. Start with operational ownership for user journeys, scheduled jobs, data areas, or business capabilities that teams can identify and measure.

The first work is often better telemetry, safer deployment, dependency mapping, and clearer incident roles. Splitting code into services before those practices exist can multiply operational surfaces without resolving responsibility.

Small teams and global coverage

A small company may be unable to staff separate rotations for every service or provide continuous local coverage. It can group related services under one rotation, define business-hours support for lower-risk systems, use managed infrastructure, and reserve executive escalation for severe events.

Follow-the-sun coverage can reduce overnight disruption for global organizations, but handoffs need current incident state, explicit ownership transfer, and shared procedures. Geographic distribution does not solve unclear responsibility by itself.

How to adopt the model step by step

Adoption works best through a bounded pilot that proves the operating practices before the organization expands them. A company-wide announcement cannot create ownership records, usable alerts, or sustainable rotations.

Start with one suitable service

Choose a service with a clear user outcome, known dependencies, manageable risk, and a team willing to own both changes and production behavior. Avoid beginning with the most fragile shared system because its problems can overwhelm the learning process.

Record the service boundary, owning team, production contacts, user-facing indicators, first SLO, main failure modes, and recovery controls. Review the current page load and recent incidents before setting the rotation so staffing decisions reflect actual demand.

Build the minimum operating system

The pilot needs enough structure to make responsibility safe and measurable. Establish dashboards, actionable alerts, runbooks, severity rules, escalation paths, incident roles, and a release recovery method. Test access before an incident, including any emergency authorization process.

Schedule a response exercise using a realistic failure. Ask the responder to diagnose impact, choose a mitigation, communicate status, and verify recovery. The exercise will expose missing permissions and unclear instructions more safely than a real outage.

Use a 30/60/90 day sequence

During the first 30 days, define ownership, establish indicators and an SLO, document common failure responses, and create the initial rotation. Review the service's architecture and data recovery needs before declaring the pilot live.

During days 31 through 60, tune noisy alerts, run an incident exercise, test restoration and rollback, and review every page. Give the team capacity to remove the repeated manual work discovered during this period.

During days 61 through 90, compare outcomes with the baseline, correct workload problems, and package useful defaults for the next team. Expand to one or two more services only when the pilot can operate without routine heroics.

Track outcomes rather than ceremony

Adoption metrics should show whether the model improves delivery and operation. Useful measures include deployment frequency, change failure rate, time to restore service, SLO performance, page volume, after-hours interruptions, and repeated incident causes.

Numbers need context. A lower deployment frequency may reflect larger changes, a release freeze, or reduced demand. A falling page count may mean better reliability or disabled alerts. Review measures together and connect them to customer impact before changing policy.

Team health belongs in the review. Track rotation fairness, interrupted sleep, unfilled coverage, time spent on operational work, and whether postmortem actions receive capacity. A service can meet its SLO while exhausting the people maintaining it, which is not a sustainable operating state.

Define the expansion gate

A service is ready for this model when ownership is unambiguous, responders have safe access, alerts are actionable, common failures have procedures, recovery has been tested, and leadership funds preventive work. Teams should be allowed to say "not ready" with specific evidence.

Expansion should reuse standards without copying targets blindly. Each service needs reliability goals and coverage based on its users, failure consequences, architecture, and support commitments. The operating principles remain consistent while implementation reflects actual risk.

Where Koder.ai fits

Koder.ai can support teams creating and operating web, server, and mobile applications, but the service owner still defines reliability requirements and production procedures. The platform uses a chat interface and a mixture of agents to help technical and non-technical users create software from natural-language instructions.

Its planning mode can help a team describe application boundaries, dependencies, data needs, and operational acceptance criteria before implementation. Snapshots and rollback provide recovery controls that teams can include in release and incident procedures. Source code export preserves access to the implementation for review, testing, and continued ownership.

Koder.ai supports deployment, hosting, and custom domains. Applications can use React for web interfaces, Go with PostgreSQL for backend work, and Flutter for mobile development. Those capabilities can shorten setup, while teams still need to configure monitoring, alert thresholds, access, backups, incident roles, and user-focused objectives for each production application.

The platform offers free, pro, business, and enterprise tiers. Teams should choose a tier by deployment, support, governance, and collaboration needs rather than treating price as a substitute for an operating model. Its AWS-based global infrastructure can also support country-specific application placement when data privacy and cross-border transfer requirements demand it.

A sensible pilot starts with planning one bounded application, naming its owner, defining a measurable user outcome, and documenting how the team will detect and reverse a failed release. Build and deployment speed become durable advantages only when the resulting service is observable, recoverable, and owned after it ships.