- Date: 1 October 2013
- Day one: Six people completed an enrolment
- Obligated cost: $840 million reported by CMS as of March 2014
The background
Healthcare.gov was not a startup gambling with venture capital on an unproven idea. It was the digital front door to the Affordable Care Act's insurance marketplace, a system that Americans were legally required to use if they wanted subsidised health coverage and lived in one of the states that had chosen not to build its own exchange. The Centers for Medicare & Medicaid Services ran the project, and the launch date was not a marketing decision or a quarterly target. It was written into law: 1 October 2013.
The site had one job. It needed to let people create accounts, enter their details, compare health plans based on their circumstances, and enrol. Conceptually simple. Operationally, it meant integrating with multiple federal agencies to verify income, citizenship, and eligibility in real time. It meant presenting personalised premium quotes that depended on age, location, household size, and projected earnings. It meant handling secure financial information and connecting users to private insurers. And it meant doing all of this at a scale that was both enormous and genuinely unknowable in advance, because the population that would use it had never had reason to visit a website like this before.
By September 2011, the Federally Facilitated Marketplace obligations stood at $56 million. By February 2014, they had risen above $209 million. By March 2014, CMS reported obligating $840 million across development and supporting systems. This was not a minor IT refresh. It was one of the largest and most visible government technology projects in recent memory, and it was being watched by everyone with an opinion about healthcare policy, government competence, or the viability of large-scale software projects in the public sector.
What actually happened
The site launched as legally required on 1 October 2013. Within two hours, it crashed.
Over four million unique visitors arrived on the first day. The system had been sized for roughly one-fifth of that concurrent load. Demand reached roughly 250,000 concurrent users, about five times more than expected. Those are not the numbers of a quiet soft launch or a limited beta. They are the numbers of a system meeting the entire weight of public expectation and legal obligation at once, in production, with no way to throttle access or delay the rollout.
The front page loaded, sometimes. The account creation process mostly did not. When users managed to get through registration, the plan comparison tools timed out or returned errors. The payment workflows failed. The site did not degrade gracefully under load. It did not queue requests or present waiting screens. It simply stopped working, and four million people were left staring at error messages or spinning progress indicators that never resolved.
By the end of the first day, six people nationwide had managed to select a health plan. Not six thousand. Not six hundred. Six.
A CMS official would later state that the site had not been tested for the volumes it faced on 1 October. The Government Accountability Office, in a report published in July 2014, found that CMS had undertaken development without effective planning or oversight practices. The GAO documented cost increases, schedule slips, and delayed functionality, driven primarily by changing requirements and worsened by oversight gaps. In 2016, the HHS Office of Inspector General published a case study examining CMS management of the federal marketplace, adding another layer of post-mortem analysis to what had become one of the most scrutinised technology failures in government history.
The site was eventually stabilised and relaunched over the following weeks, but the initial failure had already become the story. For a programme whose opponents were eager to declare it unworkable and whose supporters needed a demonstration of competent execution, the first two hours were catastrophic. The technical failure became a political symbol, and the six enrolments on day one became the single number that summarised everything that had gone wrong.
The people in the room
Nobody involved in this project set out to build a system that would serve six people on launch day. The engineers knew how to build websites. The project managers knew how to track milestones. The agency officials knew the stakes. What they did not have was the ability to move the one variable that every software project uses to absorb the unexpected: time.
When requirements change late in development, you can absorb the impact by extending the schedule, reducing scope, or skipping verification work. The launch date was fixed by law, which removed the first option. The scope was defined by statute and regulation, which made the second option politically and legally fraught. That left the third, and testing is always the work that feels most deferrable when a deadline is imminent. A feature that is not written is visibly absent. A test that is not run is invisible until production traffic arrives.
The decision to launch untested at the expected volumes was not reckless. It was the logical outcome of a constraint set that left no good options. When you cannot move the date and you cannot credibly reduce what the system must do, you ship what you have and hope the estimates were pessimistic. In this case, they were optimistic by roughly a factor of five, and hope was not enough.
The damage
- Six people completed a plan selection on the first day, out of over four million unique visitors
- The site crashed within two hours of launch
- Concurrent demand reached roughly 250,000 users, about five times the expected load
- CMS reported obligating $840 million for development and supporting systems as of March 2014
- Federally Facilitated Marketplace obligations rose from $56 million in September 2011 to more than $209 million by February 2014
What actually went wrong
The immediate cause was a capacity failure. The site was not built to handle the load it received. But capacity was a symptom, not the disease. The GAO's findings pointed at something less dramatic and more structural: development proceeded without effective planning or oversight, and requirements kept changing while nobody held the authority or the political capital to stop them changing.
In a normal software project, evolving requirements are managed by adjusting scope or schedule. If a new feature is added in month eight of a twelve-month project, you either cut something else or you push the launch to month thirteen. Healthcare.gov had no month thirteen. The law specified 1 October 2013, and moving that date would have required legislative action in a Congress that could barely agree on anything related to healthcare policy. The project absorbed every requirement change, every scope expansion, and every integration complexity by compressing the testing and stabilisation phases at the end.
Load testing is not optional infrastructure work you do if there is time left over. It is the only way to know whether a system will survive contact with real users. An untested system meeting traffic for the first time in production does not degrade gracefully. It falls over, hard, because every bottleneck and race condition and resource leak that would have been caught in a load test all trigger at once under real demand. The site was not tested at 1 October volumes because there was not time to test at 1 October volumes, and there was not time because the date could not move and the scope would not shrink.
The load estimate was also off by a factor of five, but that matters less than it sounds. A system that had been properly load tested at even half the actual traffic would have revealed its breaking points and given engineers time to fix them. A system that meets four million visitors for the first time on launch day has no chance. The concurrency estimate was wrong, but the absence of testing was the failure.
What small businesses can learn
- If the launch date cannot move, the scope must give. A fixed deadline is a constraint on everything else in the project, and teams under that constraint will always sacrifice testing first because it is the least visible cut. Make scope reduction an explicit, managed process rather than an implicit failure mode.
- Load testing is not optional. If your system has not met realistic traffic volumes before launch, it will fail in production. Budget time for load testing as a mandatory phase, not as a nice-to-have if the schedule permits. An hour of load testing will tell you more about your system's real behaviour than a week of code review.
- Changing requirements are expensive in ways that do not show up in feature counts. Every late change compresses the testing window and increases the likelihood that critical integration points have not been verified. If requirements are still shifting a month before launch, the launch date is wrong. See our developer tools coverage for infrastructure that can help you test and deploy with more confidence.
- Untested systems do not degrade under load, they collapse. There is no middle ground between "works fine" and "serves six users out of four million". Plan for graceful degradation, but understand that it only works if you have tested the degradation path itself.