Cloudflare outage (Nov 18, 2025): what code review catches

November 18, 2025. Cloudflare crashed. X stopped loading. ChatGPT went dark. Spotify quit playing.

Cloudflare called it its worst outage since 2019.

The cause? A database permissions change caused a bot management configuration file to exceed its size limit. The file doubled in size. Proxies on Cloudflare's newer FL2 engine panicked when they loaded it and returned errors, while the older FL engine kept running but gave every request a bot score of zero.

TLDR

Cloudflare's November 2025 outage started when a bot management file exceeded a size limit and the proxy code that read it panicked. The root cause was a latent bug in the code, combined with a database change. The incident shows why code quality, thorough testing, and automated review matter. Teams using repository-wide code review catch issues before they reach production. The same checks apply to AI-written code, which our guide to AI code security covers.

What went wrong at Cloudflare

Cloudflare shared a post-mortem explaining what caused the outage.

A bot management feature file gets generated from database queries. The code had a hardcoded size limit based on the expected file size. A change to database permissions altered query behavior, causing the feature file to contain duplicate rows.

The file doubled in size and exceeded the hardcoded limit. When proxy processes tried to load it, they crashed, flooding Cloudflare's network with HTTP 500 errors and taking down dependent services.

The query that built the file relied on an old assumption that it would only see columns from the "default" database. It only failed when the permissions change broke that assumption.

Why this matters for every engineering team

Cloudflare runs internet infrastructure at a massive scale with world-class engineers. They still shipped code with a latent bug that caused a global impact.

1. Hidden assumptions break in production

The code assumed bot management files would stay within certain size bounds. That assumption held until it didn't. When the database change triggered larger files, the hardcoded limit became a critical failure point.

Code review that understands repository-wide context catches these assumptions. For microservice systems, tools analyzing entire codebases identify hardcoded limits that could fail under different conditions.

2. Small changes have large impacts

A database permissions update seems routine. It triggered a cascade affecting millions of users. The relationship between the database change and the bot management code wasn't obvious during review.

Infrastructure and dev teams maintaining shared services need code review that traces dependencies across repositories. Changes to one component affect systems that depend on it.

3. Testing doesn't catch everything

Cloudflare's postmortem doesn't say why testing missed it. The first automated test flagged the problem at 11:31 UTC, after errors had already reached customer traffic.

Comprehensive code quality checks examine edge cases and boundary conditions that tests miss. Automated review flags hardcoded limits, unvalidated assumptions, and potential failure modes before code reaches production.

The cost of code quality

Even small bugs in critical systems can have huge consequences. The points below show how code issues affect users, businesses, and entire infrastructure, and why proactive review matters.

1. Immediate impact on businesses

Cloudflare's outage started at 11:20 UTC. Core traffic was largely flowing again by 14:30 UTC, and all systems were back to normal at 17:06 UTC. Affected businesses saw e-commerce orders fail, SaaS platforms go offline, and API-dependent applications break.

2. Prevention vs reaction

Cloudflare's team reacted quickly, diagnosing and fixing the issue within hours. But reaction, no matter how fast, still means downtime. Prevention catches problems before they affect users.

Teams shipping code that powers critical infrastructure can't afford to find bugs in production. The window between deployment and incident is too short. Speed and quality don't conflict when review processes catch issues automatically.

3. Multiple systems impacted by a single failure

The initial bug affected proxy processes. Those failures cascaded to Workers KV, Cloudflare Access, the dashboard, and dependent services. Cloudflare's postmortem lists six affected services in all, including Turnstile and Email Security.

Code quality tools that understand system architecture identify potential cascade points. When changes affect shared infrastructure, the code review should flag dependencies that could fail.

What code review should catch

The Cloudflare outage highlights specific patterns that automated code review needs to identify.

1. Check hardcoded limits

The bot management code did check the file against its limit of 200 features. When the file went over the limit, the check returned an error that the FL2 code never handled, so the proxy panicked.

Code review should flag any hardcoded limit that lacks corresponding validation. If the code assumes data stays below X size, the review should verify error handling for data that exceeds X. Bug Bench tracks which AI models write the most error-handling bugs in the code cubic reviews.

2. Watch hidden dependencies

The database permissions change affected bot management file generation. That dependency wasn't obvious from either component independently. Changes to the database didn't show which services depended on specific query behaviors.

Repository-wide analysis traces these dependencies. When one component changes, the review identifies other components that could be affected.

3. Assumptions about runtime conditions

The code assumed files would stay within certain sizes. This assumption held under normal conditions but failed when conditions changed. The assumption was implicit, not documented or validated.

AI review that learns team patterns identifies undocumented assumptions. When code makes implicit assumptions about data size, timing, or behavior, automated review flags those assumptions for validation.

4. Handle edge cases

When the file exceeded size limits, the system crashed. The code lacked graceful degradation, error logging, or fallback behavior for the unexpected case.

Quality checks verify error handling for edge cases. What happens when the data is larger than expected? When do services time out? When dependencies fail? Code should handle these scenarios explicitly.

How can cubic’s AI Code Review Tool catch issues like this?

cubic uses AI code review to detect patterns that caused incidents like Cloudflare’s outage.

1. Repository-wide context

cubic analyzes entire codebases, not just changed files. When database code changes, cubic traces that services depend on that database's behavior. Dependencies that aren't obvious from file-level review become visible.

2. Custom agents

Teams write review rules in plain English as custom agents, such as "All file processing must validate size limits before loading" or "Hardcoded limits require corresponding error handling", and cubic checks every pull request against them.

3. Learning from your team

cubic learns from replies and reactions to its review comments and from your senior engineers' past reviews. When an incident reveals a pattern that review should catch, add it as a custom agent and cubic checks every pull request against it.

4. Automated checks before merge

Issues get flagged during code review, before merge, before deployment. The feedback loop shortens from production incident to PR comment.

5. Codebase scans for latent bugs

PR review catches issues in new code. But Cloudflare's failure came from code that worked until a change elsewhere fed it a file twice the usual size. Most codebases contain years of code written before AI review coverage existed.

cubic's codebase scans analyze your entire repository to find bugs hiding in existing code. Thousands of AI agents explore your codebase in parallel, tracing data flows across files and verifying whether potential issues are actually exploitable. They find hardcoded limits without validation, hidden cross-component dependencies, race conditions, and business logic flaws that pattern-matching tools miss.

Unlike traditional scanners that flood you with false positives, codebase scans investigate each finding before reporting it. The result is high-confidence issues you can fix immediately.

What engineering teams should do differently?

The lessons from Cloudflare's outage apply to every team shipping code to production. Here’s what engineering teams can do to avoid similar problems.

1. Question hardcoded assumptions

When code contains hardcoded limits, timeouts, or size constraints, verify what happens when those limits are exceeded. Add validation, error handling, and monitoring so the system fails safely instead of crashing.

2. Trace cross-component dependencies

Map which services read a component's data or depend on its behavior, and check them when that component changes.

3. Test edge cases

Most systems work fine under normal conditions. Problems show up when data gets much bigger than expected, services slow down, or assumptions no longer hold. Testing should include these edge cases, not just ideal scenarios.

4. Implement gradual rollouts

Deploy changes incrementally. Monitor behavior. Catch issues when they affect a small percentage of traffic, not the entire network.

5. Maintain code quality as a priority

Quality isn't a feature you ship later; it's a feature you ship earlier. It's a foundation that prevents incidents. Teams that prioritize quality during development avoid expensive fixes in production.

Code quality prevents incidents

Cloudflare's outage demonstrates what happens when latent bugs reach production at scale. The team restored core traffic in about three hours, published a detailed postmortem the same day, and listed the hardening work it had started. This transparency helps the entire industry learn.

The lesson is clear. Code quality matters because production incidents are expensive, disruptive, and entirely preventable. Better review processes catch issues before deployment. Repository-wide analysis identifies dependencies that file-level review misses. Automated quality checks flag assumptions, validate limits, and verify error handling.

Every team ships code with the potential to cause incidents. The question is whether you catch issues in review or in production. cubic integrates AI-powered code review and automated quality checks directly into your workflow, helping teams catch bugs, validate assumptions, and enforce standards before deployment.

Ready to improve code quality before deployment?

Book a demo with cubic to see how repository-wide analysis and automated quality checks catch issues that file-focused reviews miss.