The Cloudflare Blog – Brought to You by EmDash  🔗 **Source:** [The Cloudflare Blog – Brought to You by EmDash](https://blog.cloudflare.com/cloudflare-blog-uses-emdash/) > [!note]+ Document Notes > > [!info] Provenance > > **Analysis generated:** 2026-08-27 by Claude (Opus 5) via the `readwise-deep-read` pipeline. > > **Source:** The Cloudflare Blog — https://blog.cloudflare.com/cloudflare-blog-uses-emdash/ > > **Published:** 2026-08-24 · **Length:** 2,103 words · 11 headings · article (engineering write-up) > > **Byline:** **Not present in the captured markup**; Reader's `author` is the bare domain. Written in first-person plural throughout on behalf of the team. No individual is asserted. > > **Register key:** `[STATED]` author-stated · `[EVIDENCE]` demonstrated · `[INFERENCE]` reviewer inference · `[RECOMMEND]` reviewer recommendation. > > **Coverage:** Full article read. Diagrams, before/after screenshots, and Lighthouse charts are referenced and **not captured** — performance claims below are as narrated, not as shown. > > **Note on my own expectation:** `[INFERENCE]` From the URL I expected an essay about the em-dash as an AI writing tell. **EmDash is a CMS product name** and this is a migration write-up. Recorded because the wrong prior shaped nothing in the analysis, but the title is genuinely ambiguous. > > **Vendor context:** `[EVIDENCE]` Cloudflare writing about migrating to a CMS built for Cloudflare, closing with *"try out EmDash today."* Self-evident from the framing. > > # 🏷️ Title: The Cloudflare Blog – Brought to you by EmDash > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References `[EVIDENCE]` No outbound links captured. Named: - **EmDash** — the CMS, *"built especially to work on Astro and with Cloudflare"*, **pre-1.0** at migration - **k6** — *"an open-source performance testing tool"* - **Kumo** — Cloudflare's design system - **Workers Cache**, **Workers KV**, **Hyperdrive**, **PlanetScale**, **MCP** - Cloudflare's internal engineering standards, *"known as our Codex"* ## 📝 Summary **What happened.** `[STATED]` On **12 August 2026** Cloudflare moved its blog to **EmDash**, a pre-1.0 CMS, and redesigned the frontend at the same time. **The rollout is the most reusable part**, and it is properly cautious: - `[STATED]` A **proxy Worker** routing between legacy and new, setting a *"version cookie"* for sticky assignment - `[STATED]` **Automatic fallback to the legacy blog** *"if the new site experienced any 500 errors"* - `[STATED]` A **service binding** (`NEW_BLOG`) dispatching worker-to-worker rather than *"through a public hostname, DNS, TLS, and an outbound HTTP connection"* - `[STATED]` Traffic ramped **1% → 5% → 15% → beyond → 100%** across launch day **Load testing with thresholds fixed in advance** — k6, three scenarios (**Ramp** to 3× baseline, **Breakpoint** 0→100 RPS over 10 minutes, **Burst** to 7,000 RPS), with pass/fail defined before the run: `[STATED]` availability fails above **0.01% 5xx**; **P95 < 500 ms**; **P99 < 1000 ms**; checks rate **> 0.99**. **The architecture.** `[STATED]` EmDash on a Worker → new **Workers Cache** (*"we believe as the first major site to do so"*) → **EmDash object cache on Workers KV**, *"which the EmDash team built specifically for our use case"* → **Hyperdrive** + **PlanetScale**. `[STATED]` Result: *"99.5% of static files from a cache and 70% of requests from a cache."* **Bottom line.** `[INFERENCE]` An honest, well-structured migration write-up with a genuinely portable rollout pattern. **Three things to hold: the production evidence is far below the tested load, the recipe includes a component built for them, and the accessibility claim has no criterion attached.** ## 📖 Main Content ### The rollout pattern is the thing to steal `[INFERENCE]` Four decisions, each of which is the one most teams skip: 1. **A proxy in front of both systems**, so the migration is a routing change rather than a cutover. 2. **A version cookie**, so a given reader stays on one experience instead of flapping between two. 3. **Automatic fallback on 5xx** — `[STATED]` *"this strategy allowed us to fall back to the legacy blog if the new site experienced any 500 errors."* `[INFERENCE]` **This is the load-bearing one.** A percentage rollout without an automatic reversal is a slower way to have the same outage. 4. **Percentage ramp with validation gates** — 1%, 5%, 15%, then up, *"as we validated system health."* `[EVIDENCE]` And it worked as designed: `[STATED]` *"This phased approach allowed us to observe how the platform handled real-world production load while catching a few last-minute edge cases without impacting the vast majority of our audience."* `[INFERENCE]` **The service-binding detail is the Cloudflare-specific optimisation and the rest is platform-agnostic.** Any stack with a reverse proxy can do proxy + cookie + fallback + ramp. `[RECOMMEND]` **The transferable rule: a staged rollout is only safe if the stage can reverse itself without a human.** ### The load testing is disciplined, and the production evidence is much weaker than it `[EVIDENCE]` **Thresholds were defined before testing** — the k6 `thresholds` block is quoted in the post, with `http_req_failed: rate<0.01`, `p(95)<500`, `p(99)<1000`, `checks: rate>0.99`. `[INFERENCE]` **Deciding what failure means before you run the test is the whole discipline**, and it is the same principle as requiring a negative control before accepting a detector. `[INFERENCE]` **But the numbers across the piece do not line up as strongly as the framing suggests:** | Figure | Value | Source | |---|---|---| | Normal baseline | `[STATED]` ~**75 RPS** | pre-migration observation | | Claimed pre-migration spikes | `[STATED]` *"over **5,000 RPS**"* | pre-migration observation | | Burst test | `[STATED]` **7,000 RPS** | synthetic | | **Post-migration peak observed** | `[STATED]` *"up to **850 RPS**"* | production | | Agents Week peak | `[STATED]` *"up to **450 RPS**"* | production | `[INFERENCE]` **The best production evidence is 850 RPS — about 12% of the tested burst and roughly a sixth of the claimed historical spike.** That is not a contradiction: they may simply not have had a 5,000 RPS moment since 12 August. But `[STATED]` *"We've seen all these performance gains – and minimal errors – while serving up to 850 RPS"* **is a much weaker validation than the 7,000 RPS test implies**, and the two figures sit close enough together in the piece to read as mutually reinforcing when they are not. `[RECOMMEND]` **The stress test validates the architecture in theory; the production record so far validates it at roughly a seventh of the load the old system was said to face.** Both are true and the post does not separate them. ### The DDoS figure is doing work it cannot support `[STATED]` Under *"The first test: Agents Week"*: *"Thanks to Cloudflare's built-in DDoS protection, we also absorbed a **28,000 RPS DDoS attack on August 10th**, also without any noticeable issues."* `[INFERENCE]` **The migration was 12 August. The attack was 10 August — two days before.** So whatever absorbed it, **it was not the new EmDash stack**, and the post attributes it to *"Cloudflare's built-in DDoS protection"* rather than to the new architecture, which is accurate. `[INFERENCE]` **The problem is placement, not accuracy.** Appearing inside the section framed as the new blog's first test, alongside the new blog's RPS figures, a 28,000 RPS number reads as evidence about the new platform. **It is evidence about Cloudflare's edge, which protected the old platform too.** `[INFERENCE]` I cannot tell whether Agents Week straddled the migration date — if it did, part of it ran on the legacy blog, which would make the section's framing looser still. ### Pre-1.0 in production, and scheduled posts broke twice `[EVIDENCE]` The post is refreshingly plain about the risk: `[STATED]` *"This is something you'd want to know broadly about any new platform, but especially one that's **pre-1.0**."* `[EVIDENCE]` And about the biggest gap: `[STATED]` *"The biggest oversight we found was around **scheduled posts, which didn't work until EmDash version 0.19.0**… it was also definitely something we didn't want to be finding out after the scheduled time for a post."* `[EVIDENCE]` **Then it happened again after migration.** `[STATED]` During Agents Week: *"we also found some bugs specifically around scheduled posts. We've since raised these to the EmDash team and are confident that they'll be fixed before Birthday Week."* `[INFERENCE]` **Scheduling — the single most consequential function of a publishing CMS — broke twice, once before launch and once after.** Reporting both is the piece's strongest credibility move, and it is reported without dwelling. ### The Customer Zero policy is evidence against itself, read only one way `[STATED]` *"The burden of proof is on you if you want to use an external vendor. Why can't that team support you, what gaps are there, why can't those gaps be filled, and **are those 'gaps' true requirements?**"* — `[STATED]` and this is *"enshrined in our internal engineering standards, known as our Codex."* `[INFERENCE]` **That last clause is the tell.** Putting the burden on the requester to justify their *requirements* — with "gaps" in scare quotes — is a policy that will, applied consistently, route teams onto internal tooling that does not yet do what they need. **That is not a hypothetical: it is what this post describes happening.** `[INFERENCE]` **The post is simultaneously the best case for the policy and the clearest documentation of its cost, and reads it only as the former.** The benefits are real and stated — `[STATED]` *"If a product breaks, it breaks us first. This forces us to fix issues immediately"* — and so is the price: a pre-1.0 CMS on a property taking 5,000 RPS spikes, with scheduling broken twice. `[RECOMMEND]` `[INFERENCE]` **The honest version is a trade-off with a threshold**: dogfooding is valuable, and *"are those gaps true requirements?"* is a question that should have a defensible answer for scheduled publishing on a major blog. **The piece never asks what would have made the answer "no, we should use a vendor."** ### The reproducibility caveat is one clause and matters a lot `[STATED]` *"Using the new EmDash object cache built on Workers KV, **which the EmDash team built specifically for our use case**."* `[INFERENCE]` **The published architecture includes a component that exists because Cloudflare asked for it.** A reader following the recipe gets EmDash-on-a-Worker, Workers Cache, Hyperdrive and PlanetScale — and a cache layer whose origin story is "we were the first customer and they built it." `[INFERENCE]` **This is the Customer Zero dynamic working exactly as advertised, and it is also the limit on the write-up's transferability.** Combined with `[STATED]` *"we believe as the first major site to [use Workers Cache]"*, **two of the four architectural layers were novel or bespoke at the time of writing.** The post is honest about both facts and does not draw the conclusion: **the performance results are not straightforwardly reproducible by a reader.** ### The accessibility claim has no criterion attached `[STATED]` *"We implemented theme switching tied directly to system preferences, alongside an explicit toggle, and **ensured that accessibility guidelines were strictly met across both themes**."* `[INFERENCE]` **"Strictly met" is a strong claim and nothing supports it** — no standard named, no conformance level, no criterion, no audit, no tooling. `[INFERENCE]` For a redesign that added dark mode, the specific risk is well known and unaddressed here: **a palette that passes 1.4.3 in one theme can fail in the other**, and syntax highlighting is the usual casualty because token colours are tuned for one background. `[EVIDENCE]` The post does say the palette and highlighting *"adapt seamlessly without sacrificing legibility"* — `[INFERENCE]` which is an aesthetic claim, not a contrast measurement. `[RECOMMEND]` `[INFERENCE]` **The theme-switching implementation described is the right pattern** — system preference plus explicit toggle, which handles all three states correctly. **The verification claim is the unsupported part**, and the fix is one sentence: name the standard and the level. `[INFERENCE]` It also connects to the per-breakpoint finding from earlier in this batch: **dark mode multiplies the contrast test matrix exactly as responsive overrides do**, and in both cases nothing in the tooling checks the non-default state. ### The subscription-box finding is small, specific, and generalisable `[STATED]` *"Previously, the subscription box lived in the top right corner of the page. Because of its placement, **readers frequently mistook it for a search bar and typed their search queries directly into the input field.**"* `[INFERENCE]` **Position implies function, and it overrides the label.** A single input field in the top-right of a content site is a search box by convention, and readers acted on the convention rather than on whatever the field said. **The fix was relocation, not clearer labelling** — which is the right diagnosis. `[RECOMMEND]` The transferable version: **when users misuse a control, check whether its position is making a promise its label contradicts.** `[INFERENCE]` And the detection method is worth noting — they found this because search queries were arriving as email signups, i.e. **the failure was visible in the data before anyone reported it.** ### Two MCP servers, and one of them is a bet on the batch's AI-search claim `[STATED]` A blog MCP server exposing `search_posts`, `list_posts`, `get_post`, `list_tags` — `[STATED]` *"creating this new MCP took just a few hours of work."* And EmDash's own MCP for authors: *"browse, create, and edit content, publish and schedule posts, remove files."* `[STATED]` *"reflecting a growing trend of designing for agents, as well as humans."* `[INFERENCE]` **This is a concrete instance of the claim Daryn Strauss made in this batch** — that people increasingly get information from AI tools rather than from search on the publisher's site. **A publisher exposing an MCP server is making itself readable by the thing that replaced its search box.** `[INFERENCE]` Whether that is prescient or premature is unknowable now; **it costs a few hours, which is the right size of bet on an uncertain trend.** `[INFERENCE]` And it pairs with the Kent Dodds material from this batch — *"an MCP server is a website for the agent"* — where the design question is curation rather than exposure. **Four tools is a curated surface, not an API dump**, which is the right shape by that standard. ## 🗒️ Notes - **Vertical integration collapses the three-way separation.** `[INFERENCE]` The Dries pieces in this batch describe open-source infrastructure where **benefit, cost, and decision authority sit with different parties**. Cloudflare running its blog on its own CMS, its own Workers, its own cache, and its own edge is the **degenerate case: all three collapse into one org.** `[INFERENCE]` That is why the migration could be this aggressive — *"if a product breaks, it breaks us first"* is only a virtue when the breaker and the bearer are the same party. - **The cache figures are the clearest performance evidence:** `[STATED]` *"99.5% of static files from a cache and 70% of requests from a cache."* `[INFERENCE]` A 70% origin-offload rate is what makes the database and Worker load tractable, and it is a more meaningful number than the RPS figures. - **The p95 comparison is described and not shown:** `[STATED]` the old platform had *"periodic latency spikes under load"* while the new one is *"remarkably flat."* `[INFERENCE]` The chart is referenced; no figures are given. **"Flat" is the claim; the numbers are in an image the extraction did not capture.** - **Agents Week scale:** `[STATED]` *"18 new posts over 9 days"*, *"close to 3 million pageviews."* `[INFERENCE]` Roughly 333k pageviews/day sustained, which at 450 RPS peak suggests very effective caching rather than heavy origin load. - **The gaps list is candid and specific**, which is rare in migration write-ups: `[STATED]` media and content-entity search at scale, bylines, localisation, SEO, CSPs, custom HTML block findability, in-entity editor bugs, and **a formatting toolbar that scrolled out of view on long posts.** `[INFERENCE]` That last one is a real editorial-workflow defect and the kind of thing only actual use finds. - **"Available without any additional cost"** for the authoring MCP. `[INFERENCE]` A pricing claim in a post that ends *"try out EmDash today"* — accurate as far as anyone can tell, and it is marketing. - **"Confident that they'll be fixed before Birthday Week"** — `[INFERENCE]` a forward-looking assurance about someone else's roadmap, stated in a post recommending that product. **The one place the write-up's independence is thinnest.** - **Three innovation weeks are referenced** (Agents Week, Birthday Week) as recurring load events. `[INFERENCE]` Having predictable traffic spikes on a known calendar is a genuine advantage for capacity planning that most sites do not have. ## 📚 References `[EVIDENCE]` **No outbound links captured**, including to EmDash itself, k6, the Kumo design system, or the MCP specification — in a post whose closing call to action is *"try out EmDash today."* `[INFERENCE]` The k6 configuration is **quoted in full as code**, which is the strongest reference practice in the piece: a reader can copy the thresholds and scenario shape directly. `[INFERENCE]` **That one code block is worth more than a list of links** — it is the reproducible part. `[INFERENCE]` Everything else — Lighthouse scores, p95 comparison, architecture diagram, before/after screenshots — is **in images the extraction did not capture**, so the quantitative claims are narrated rather than shown to a text reader. ## 🗣️ Paraphrase Cloudflare moved its blog to EmDash, a CMS built for Astro and Cloudflare, on 12 August, and redesigned the frontend at the same time. They did it because Cloudflare treats itself as Customer Zero — internally, the burden of proof falls on anyone who wants to use an outside vendor. EmDash was pre-1.0, so they checked two things first: does it work, and does it scale. On the first, they ran normal editorial flows and found gaps around scale, localisation, SEO, CSPs, and editor usability — the worst being that scheduled posts didn't work at all until version 0.19.0. On the second, the blog normally takes about 75 requests per second and spikes past 5,000. They used k6 to run a gradual ramp, a breakpoint test, and a sudden burst to 7,000 RPS, with failure defined in advance: more than 0.01% server errors, p95 over 500ms, or p99 over 1000ms. The resulting architecture runs EmDash on a Worker behind the new Workers Cache, with an object cache on Workers KV that the EmDash team built for them, and Hyperdrive talking to PlanetScale. They now serve 99.5% of static files and 70% of requests from cache. For the cutover, a proxy Worker sat in front of both blogs, set a version cookie, and fell back to the legacy site on any 500 error. They ramped from 1% to 5% to 15% and up, reaching 100% by end of day. The redesign brought dark mode with a system-preference default and a toggle, moved the email signup out of the top-right corner — where readers kept mistaking it for a search box — and added a table of contents and sharing sidebar. Afterwards, latency is flatter, they've served up to 850 RPS, and Agents Week put 18 posts and nearly 3 million pageviews through it at up to 450 RPS. Scheduled posts had bugs again. ## 📰 Newsletter **Cloudflare moved its blog to a pre-1.0 CMS, and the rollout pattern is the part worth stealing.** Four decisions, and the third is the one most teams skip: a **proxy Worker** in front of both old and new; a **version cookie** so readers stay on one experience; **automatic fallback to the legacy site on any 500 error**; and a ramp from **1% → 5% → 15% → 100%** across launch day. **A staged rollout is only safe if the stage can reverse itself without a human** — otherwise it's just a slower way to have the same outage. **The load testing is properly disciplined too** — k6, three scenarios up to a 7,000 RPS burst, with failure defined *before* the run: >0.01% 5xx, p95 >500ms, p99 >1000ms. The config is quoted in full, which makes it the most reusable thing in the post. **But watch the numbers.** The burst test was 7,000 RPS. The best production evidence is *"up to 850 RPS"* — about **12% of what they tested** and roughly a sixth of the >5,000 RPS spikes they say the old blog used to see. Not a contradiction; they may just not have had a big spike since. But the two figures sit close enough together to read as mutually reinforcing when they aren't. And the **28,000 RPS DDoS is dated 10 August — two days before the 12 August migration**, so whatever absorbed it, it wasn't the new stack. The post credits Cloudflare's edge, correctly; it's the placement inside "the first test" section that misleads. **The honest core is that scheduled posts broke twice** — didn't work at all until EmDash 0.19.0 pre-launch, then broke again during Agents Week. Reporting both is the piece's best credibility move. **Two things limit how much you can copy.** The architecture includes *"the EmDash object cache built on Workers KV, **which the EmDash team built specifically for our use case**"* — and they were *"the first major site"* on Workers Cache. **Two of four layers were bespoke or brand-new**, which the post says plainly and never connects to reproducibility. **And one for the a11y file.** They *"ensured that accessibility guidelines were strictly met across both themes"* — **no standard named, no level, no criterion, no audit.** The theme-switching pattern itself is right (system preference plus explicit toggle). But **dark mode multiplies the contrast matrix exactly the way per-breakpoint styling does**, and syntax highlighting is the usual casualty. "Adapt seamlessly without sacrificing legibility" is an aesthetic claim, not a measurement. Small gem: readers kept **typing search queries into the email signup box** because it sat top-right. Position implies function and overrides the label — and they caught it because the failure showed up in the data before anyone reported it. ## ✅ Action Items #### DevRel - **Developer advocacy:** `[RECOMMEND]` The **fallback-on-5xx proxy** is a talk. Percentage rollouts are common; automatic self-reversal is not, and it is what makes the percentage meaningful. - **Education:** `[RECOMMEND]` Teach **thresholds-before-testing** using the quoted k6 config. `[INFERENCE]` Defining failure in advance is the discipline; the tool is incidental. - **Developer experience:** `[INFERENCE]` The subscription-box finding is a reusable heuristic — **when users misuse a control, suspect its position before its label.** - **Developer marketing / Community management / Cross-project:** Not applicable to this source. #### OSPO - **Policy & Governance:** `[INFERENCE]` The Customer Zero policy is worth examining rather than adopting. **"Are those 'gaps' true requirements?" puts the burden on the requester**, and this post documents where that leads: a pre-1.0 CMS on a major property with scheduling broken twice. `[RECOMMEND]` Any dogfooding mandate needs a stated threshold at which "use the vendor" is the correct answer. - **Software Inventory:** `[INFERENCE]` The bespoke-component caveat generalises — **an architecture write-up that includes a component built for the author is not a recipe.** Worth checking for before copying any reference architecture. - **Security Management / License Compliance / Developer Support / Community Engagement / Strategic Alignment:** Not applicable to this source. #### Community - **Maintainers:** `[RECOMMEND]` The proxy-plus-cookie-plus-fallback pattern is platform-agnostic; only the service binding is Cloudflare-specific. - **Contributors / Sponsors / Ecosystem:** Not applicable to this source. #### WordPress - **Design:** `[RECOMMEND]` The theme-switching pattern — **system preference default plus explicit toggle** — is the correct three-state handling and matches what block themes need. - **Accessibility:** `[RECOMMEND]` **Dark mode multiplies the contrast test matrix**, the same way per-breakpoint overrides do (per the Ollie analysis earlier in this batch). `[INFERENCE]` Both are non-default states nothing currently checks, and **both belong in the Accessibility Lab plugin's real-time validator.** - **Core Performance:** `[INFERENCE]` The 70% origin-offload figure is the number that makes the rest work, and it is a more useful benchmark than RPS. - **Documentation:** `[INFERENCE]` "Accessibility guidelines were strictly met" with no standard named is the pattern to warn against — **a conformance claim needs a criterion and a level or it means nothing.** - **All other WordPress teams:** Not applicable to this source. #### The WPOCC - **Programs / Projects / Funding experiments:** Not applicable to this source. `[INFERENCE]` One adjacent observation: this migration was affordable because **Cloudflare owns every layer** — the opposite of the situation the Dries pieces describe, and not a model available to a project that depends on infrastructure it does not fund. ### FAIR - `[INFERENCE]` Not directly applicable. **One structural contrast worth recording:** where the Dries analysis describes benefit, cost, and decision authority sitting with three different parties, Cloudflare collapses all three into one organisation — **which is precisely why *"if a product breaks, it breaks us first"* is a virtue here and would be a liability in a federated ecosystem** where the breaker and the bearer are different people. ## 🧪 Hypotheses 1. **H1 — Automatic rollback distinguishes safe rollouts.** Staged rollouts with automatic error-triggered fallback show materially lower user-visible incident duration than staged rollouts requiring human intervention. 2. **H2 — Dark mode introduces contrast regressions.** Sites adding a dark theme show a higher rate of 1.4.3 failures in the non-default theme than in the default one. 3. **H3 — Position overrides label for input affordances.** A single input in a conventional search position is used for search regardless of its label or placeholder, at a substantial rate. 4. **H4 — Dogfooding mandates delay capability.** Organisations with vendor-burden-of-proof policies adopt internally-built tooling before feature parity at a higher rate, with measurable workflow cost. 5. **H5 — Reference architectures containing bespoke components are not reproducible.** Published architectures including a component built for the author yield materially worse results when replicated. 6. **H6 — Agent-readable endpoints will attract traffic.** Publishers exposing MCP servers see measurable agent-originated retrieval within a year, consistent with the claimed shift of informational queries away from site search. ## 📊 Methodology - **H1 — the most valuable and the hardest to instrument externally.** Compare incident duration across rollouts with and without automatic fallback, using public postmortems. **Confound:** teams that build automatic fallback are more mature generally, so the mechanism and the maturity are entangled — **needs a within-org before/after, not a cross-org comparison.** - **H2 — mechanical and immediately runnable.** Crawl sites offering both themes; compute contrast ratios per theme; compare failure rates. `[RECOMMEND]` **Same design as the per-breakpoint test from earlier in this batch, and the two could share a harness** — both measure a non-default state that tooling ignores. - **H3 — a clean, cheap usability experiment.** Present the same input in search position versus elsewhere, varying label; measure misuse. `[INFERENCE]` **Cloudflare's own detection method is the better field version** — look for search-shaped strings in email signup data, which requires no participants at all. - **H4:** Case comparison of internal-tool adoption timing against feature parity. **Confound:** "parity" is defined by the adopting team and post hoc. Fix the requirement list in advance or the result is unfalsifiable. - **H5:** Attempt replication of published reference architectures; compare achieved performance. `[INFERENCE]` **Expensive, and the honest cheaper version is a survey**: how many published reference architectures disclose a bespoke component? This post does, in one clause, which is more than most. - **H6 — pure observation, and the interesting one.** Track agent-originated requests against the MCP server over 12 months. `[INFERENCE]` **Cloudflare is unusually well placed to answer this and has the data**; a follow-up post with those numbers would be the strongest available test of the AI-search claim circulating elsewhere in this batch. ## ❓ Questions - **Has the new stack actually seen a 5,000 RPS spike?** `[INFERENCE]` The tested burst was 7,000 and the best reported production figure is 850 — **the architecture is validated in the lab and lightly exercised in production so far.** - Did Agents Week straddle the 12 August migration? `[INFERENCE]` If so, part of *"the first test"* ran on the legacy blog, and the 28 August DDoS certainly did. - **What standard, at what level, was "strictly met"?** No criterion is named anywhere. - `[INFERENCE]` Would the architecture perform the same **without** the object cache built for them? - What was the p95 latency, in milliseconds, before and after? `[EVIDENCE]` Described as *"flat"* versus *"periodic spikes"*, with the numbers in an uncaptured chart. - `[INFERENCE]` **What would have made "use an external vendor" the right answer?** The policy is stated and its threshold never is. ## 🔮 Future Research - **Whether automatic rollback measurably changes incident outcomes**, separated from general team maturity. - **Contrast regression in non-default UI states** — dark themes and responsive breakpoints are the same untested-state problem, and neither has tooling. - **Agent-originated traffic to publisher MCP endpoints.** `[INFERENCE]` The most interesting open question here and the one Cloudflare can answer with data nobody else has. - **Reproducibility of published reference architectures.** `[INFERENCE]` A general problem this post exemplifies honestly and does not name. ## 💡 Implications - **Practice.** `[RECOMMEND]` Adopt **proxy + version cookie + automatic 5xx fallback + percentage ramp** for any migration. Define load-test thresholds **before** running. Check contrast in **both** themes. - **Policy.** `[INFERENCE]` A dogfooding mandate needs a stated exit condition. **"Are those 'gaps' true requirements?" is a question that can always be answered yes**, and this post is what that costs. - **Security.** Not applicable to this source. `[INFERENCE]` One adjacent note: CSP handling appears in the gaps list, which is a reminder that CMS migrations routinely regress security headers. - **Education.** `[EVIDENCE]` The quoted k6 config is the piece's most educational artifact — **a complete, copyable statement of what "good" means, decided in advance.** - **Funding models.** `[INFERENCE]` Not applicable directly. **The structural observation stands:** aggressive dogfooding is available to an organisation that owns every layer and bears every cost, which is the inverse of the split the Dries analyses describe. ## 🧠 Learning Styles Assessment **Reading level estimate.** `[INFERENCE]` **Flesch–Kincaid grade 12–13** — moderate sentences with dense infrastructure vocabulary. Hand estimate on 2,103 words, ±1.5 grades. `[EVIDENCE]` Some terms are glossed for a general reader (*"k6, an open-source performance testing tool"*; MCP explained as *"almost like an API for agents"*) while others are not (*Hyperdrive*, *service binding*, *Workers KV*, *CSP*) — **the gloss is applied inconsistently**, which suggests a mixed intended audience. #### 👀 Visual learners - **Present:** `[EVIDENCE]` **Heavily visual by design** — an architecture diagram, before/after screenshots, Lighthouse scores, a p95 comparison chart, and screenshots of the old and new subscription forms. - **Improve:** `[EVIDENCE]` **None of it survives the extraction, and the quantitative claims live in those images.** `[INFERENCE]` The p95 improvement — the article's central performance result — is available to a text reader only as the word *"flat."* #### 🔊 Aural learners - **Present:** Nothing. - **Improve:** `[INFERENCE]` Low value for a technical write-up built on diagrams and a code block. #### 🗣️ Verbal learners - **Present:** `[EVIDENCE]` Strong on the conceptual parts — the Customer Zero framing, the rollout narrative, and the subscription-box story are all clearly told without jargon. - **Improve:** `[INFERENCE]` The performance section leans on visuals, so the verbal channel carries the *why* well and the *how much* poorly. #### 🧩 Kinesthetic learners - **Present:** `[EVIDENCE]` **The k6 config is quoted in full and is directly copyable** — the single most actionable artifact in the piece. - **Improve:** `[INFERENCE]` The proxy Worker — arguably the more valuable pattern — is **described but not shown.** A short code sample of the cookie-and-fallback logic would have made the rollout reproducible rather than merely comprehensible. #### 🧠 Logical learners - **Present:** `[EVIDENCE]` Clean structure — two framing questions (does it work, does it scale), then answers, architecture, rollout, results — with the thresholds stated before the tests they govern. - **Improve:** `[EVIDENCE]` **The RPS figures do not cohere as presented** (7,000 tested, 850 achieved, 5,000 claimed historically), and **the 28,000 RPS DDoS predates the migration by two days** while sitting in the new platform's results section. `[INFERENCE]` A logical reader tracking numbers will notice both. #### 🧑‍🤝‍🧑 Social learners - **Present:** `[EVIDENCE]` The collaboration with the EmDash team is described warmly and specifically — feedback loops, a cache built to order, *"incredibly receptive to our feedback."* - **Improve:** `[INFERENCE]` No individual is named anywhere, on either team, in a post whose subject is two teams working together. #### 🧘‍♀️ Solitary learners - **Present:** Self-contained narrative; the k6 block is usable alone. - **Improve:** `[EVIDENCE]` **No links at all** — not to EmDash, k6, Kumo, or MCP — in a post ending *"try out EmDash today."* #### 🌿 Naturalistic learners - **Present:** Nothing. - **Improve:** `[INFERENCE]` No honest fit for an infrastructure migration write-up; manufacturing one would be padding. ## 📊 Accessibility Assessment Assessed against **WCAG 2.2 AA**, from the captured markup only. `[INFERENCE]` **Scope limit:** content structure and text as retrieved. Focus, keyboard operation, live contrast, and reflow require the rendered page and are **not assessed**; absence of a finding is not a pass. `[INFERENCE]` Holding a post that claims accessibility conformance to its own claim is fair. #### Screen reader semantics - **Present:** `[EVIDENCE]` **Excellent heading structure** — eleven headings, correctly nested `h2`/`h3`, all descriptive (*"Can EmDash scale?"*, *"Rollout strategy"*, *"Measurable performance gains"*). **WCAG 2.4.6 satisfied**, and it is the best-structured article in this batch. - **Improve:** `[EVIDENCE]` **The one image captured in the extraction has `alt=""`.** `[INFERENCE]` The post references an architecture diagram, before/after screenshots, Lighthouse scores, and a p95 chart — **all of which carry information not present in the text.** If those are the images and they are empty-alt, that is a **1.1.1 Non-text Content (A)** failure on the article's own evidence. `[INFERENCE]` **Only one image survived extraction, so this is indeterminate for the rest** — flagged as needing checking against the rendered page. - `[INFERENCE]` **The p95 chart is the acute case:** the article's central performance claim is described only as *"remarkably flat"* in prose, with the numbers in the image. **A non-visual reader cannot access the result.** #### Keyboard navigation - **Not testable from the captured markup.** `[INFERENCE]` The theme toggle is the notable control and its keyboard operability is unassessed. #### Contrast and readability - **Not testable** — no CSS captured. `[EVIDENCE]` **This is exactly where the article's own claim sits**, and it is the one thing an extraction cannot check. #### Text resizing and reflow - **Not testable from the captured markup.** `[EVIDENCE]` The post contains a code block; **wide preformatted content is the standard 1.4.10 hazard** and must scroll within its own container. Flagged as the thing to check. #### Media and captions - **Not applicable** — no audio or video. #### Forms and interactions - **Not applicable to the captured content.** `[INFERENCE]` The redesigned email subscription form and the theme toggle are the interactive surfaces and are not assessable here. #### Standards reference - **2.4.6 Headings and Labels (AA)** — **satisfied**, and notably well. - **1.1.1 Non-text Content (A)** — **likely failure / indeterminate.** One captured image has empty alt; several information-bearing images were not captured. - **1.4.3 Contrast (Minimum) (AA)** — **the article's own claim, unverifiable from here and unsupported in the text.** - **1.4.10 Reflow (AA)** — **not assessable**; the code block is the risk. ## 🌍 DEIB Assessment #### Cultural breadth - **Present:** `[EVIDENCE]` **Localisation appears in the gaps list** — *"nuances around localization, SEO, and Content Security Policies"* — so multilingual content was a real requirement, not an afterthought. - **Improve:** `[INFERENCE]` It is named as a gap and never resolved in the text. **Whether localisation works now is unstated**, in a post otherwise detailed about what was fixed. #### Inclusive language - **Present:** Neutral throughout; the EmDash team is credited generously. - **Improve:** `[EVIDENCE]` One small exclusion: *"except for those who are more terminally online"* — `[INFERENCE]` an in-group aside that costs nothing and signals audience. #### Neurodiversity support - **Present:** `[EVIDENCE]` **Strong** — eleven descriptive headings, short sections, explicit framing questions, and a linear narrative. Easy to navigate and to re-enter. - **Present:** `[INFERENCE]` The redesign's own additions help here too: an *"On this page"* table of contents that *"tracks your progress"* is a genuine navigation aid for long technical posts. - **Improve:** Nothing substantive. #### Representation - **Present:** `[EVIDENCE]` Team-level credit given warmly to the EmDash team. - **Improve:** `[EVIDENCE]` **No individual is named anywhere** — no byline, no engineer, no designer, no EmDash contributor. `[INFERENCE]` Corporate-voice convention, and it means a collaborative achievement is attributed to two organisations rather than to any people. #### Psychological safety - **Present:** `[EVIDENCE]` **Genuinely good.** The post reports its own failures without defensiveness — scheduled posts broken pre-launch **and again after**, editor bugs, a toolbar that scrolled away, and gaps found *"after"* migration. `[STATED]` *"definitely something we didn't want to be finding out after the scheduled time for a post"* is an admission most vendor-adjacent write-ups would cut. - **Improve:** `[INFERENCE]` The accessibility claim is the one place confidence outruns evidence, and it is asserted in a way that discourages checking — *"strictly met"* invites trust rather than verification. ## ✅ Logical Validity #### Strong reasoning - **Thresholds precede tests.** `[EVIDENCE]` The k6 config defines failure — 0.01% 5xx, p95 500ms, p99 1000ms — **before** the runs. `[INFERENCE]` That is what makes the results a test rather than a demonstration, and it is the piece's strongest methodological choice. - **The two framing questions are well chosen and separately answered.** *Does it work* (usability, editorial flows) and *does it scale* (load) are genuinely independent risks, and conflating them is the usual error. - **The rollout design reasons about failure rather than success**: version cookie for consistency, automatic fallback for 5xx, incremental percentages for observation. `[INFERENCE]` Each element addresses a specific way the migration could go wrong. - **The pre-1.0 risk is stated up front** rather than discovered by the reader, which frames everything that follows honestly. #### Fallacies - **Suggestive juxtaposition of incommensurable numbers.** 7,000 RPS tested, *"over 5,000 RPS"* historical spikes, **850 RPS** actually served. **Weakness:** the figures reinforce each other by proximity while measuring different things — synthetic capacity, historical load, and observed post-migration peak. **Fix:** state that the new stack has not yet faced a spike comparable to the old one's. - **Evidence attributed to the wrong subject.** The **28,000 RPS DDoS on 10 August** sits in the new platform's results section; the migration was **12 August**. `[INFERENCE]` The text correctly credits Cloudflare's DDoS protection, so this is placement rather than misstatement — **and placement is what a skimming reader takes.** - **Unsupported conformance claim.** *"Accessibility guidelines were strictly met"* — no standard, level, criterion, or method. **Fix:** one sentence naming WCAG and a level. - **Reproducibility caveat stated and not integrated.** A cache *"built specifically for our use case"* plus being *"the first major site"* on Workers Cache means **two of four layers were bespoke or novel** — disclosed honestly, never connected to what a reader can expect. - **Policy evaluated only in its favour.** `[INFERENCE]` The Customer Zero mandate produced both the successes and the scheduled-post failures described. **The post reads it exclusively as vindication.** - **Forward-looking assurance about a third party.** *"Confident that they'll be fixed before Birthday Week"* — a roadmap claim about another team, in a post recommending their product. #### Tone of voice `[EVIDENCE]` Confident engineering write-up, plural voice, concrete, and **willing to report its own failures** — the scheduled-post bugs appear twice and are not softened. `[INFERENCE]` That candour is what buys the piece credibility, and it is spent unevenly: **the operational claims are hedged and specific; the accessibility claim and the closing product recommendation are neither.** `[EVIDENCE]` The ending is unambiguously promotional — *"It's pretty amazing and – with the upcoming launch to v1 – it'll be getting even better soon."* `[INFERENCE]` The register shift is abrupt but honest about what it is; **a reader who has followed the pre-1.0 caveats can discount it appropriately.** ## 🛡️ DARVO Analysis **No DARVO pattern present, and the framework is inapplicable.** `[EVIDENCE]` DARVO — Deny, Attack, Reverse Victim and Offender — describes a response to accusation. This is a technical write-up with no accusation, no accused party, and no adversarial dimension. Checking each element explicitly rather than omitting the section: - **Deny:** `[EVIDENCE]` **Conspicuously absent.** The post volunteers that the CMS was pre-1.0, that scheduled posts did not work at all until 0.19.0, that scheduling broke **again** after launch, and that editor bugs persist. `[INFERENCE]` Reporting a recurring failure in a product you are recommending is the inverse of the denial element. - **Attack:** None. `[EVIDENCE]` The previous CMS vendor is referenced only as *"some limitations with our current CMS vendor"* — unnamed and uncriticised, where naming and blaming were both available. - **Reverse victim/offender:** None. `[INFERENCE]` One adjacent observation, recorded separately because it is **not** DARVO: this is **a company writing about migrating to its own ecosystem's product and closing with a call to buy it.** The commercial interest is self-evident from the framing rather than disclosed, which is the norm for a corporate engineering blog. `[INFERENCE]` **The candour about failures is what makes it readable as an engineering account rather than as marketing** — and the accessibility claim is the one place that candour lapses. Already logged under Logical Validity. ## 🎯 Conclusion **Bottom line.** `[INFERENCE]` An honest migration write-up with one genuinely portable pattern and three things to hold at arm's length. 1. **The rollout pattern is the thing to take.** Proxy Worker in front of both systems → **version cookie** for sticky assignment → **automatic fallback to legacy on any 500** → ramp **1% → 5% → 15% → 100%** in a day. `[INFERENCE]` **The fallback is the load-bearing element: a staged rollout that cannot reverse itself without a human is a slower way to have the same outage.** Only the service binding is Cloudflare-specific; the rest works on any stack with a reverse proxy. 2. **Thresholds before tests.** `[EVIDENCE]` The k6 config is quoted in full — 0.01% 5xx, p95 <500ms, p99 <1000ms, checks >0.99 — **defined before the runs.** That is what makes it a test rather than a demonstration, and it is the most copyable artifact in the piece. 3. **The numbers are weaker than they look together.** `[EVIDENCE]` Burst-tested at **7,000 RPS**; best production evidence *"up to **850 RPS**"* — **about 12%** — against claimed historical spikes *"over 5,000 RPS."* `[INFERENCE]` Not a contradiction, and **the architecture is validated in the lab and only lightly exercised in production so far.** The **28,000 RPS DDoS is dated 10 August, two days before the 12 August migration** — correctly credited to Cloudflare's edge, and sitting inside the section framed as the new blog's first test. 4. **Two of four architectural layers were bespoke or brand new.** `[STATED]` An object cache *"the EmDash team built specifically for our use case"*, and *"the first major site"* on Workers Cache. `[INFERENCE]` Disclosed honestly in single clauses, and never connected to the obvious consequence: **the performance results are not straightforwardly reproducible by a reader following the recipe.** **The a11y item for your file.** `[STATED]` *"Ensured that accessibility guidelines were strictly met across both themes"* — **no standard, no level, no criterion, no audit.** `[INFERENCE]` The theme-switching implementation described is the right pattern (system preference plus explicit toggle, handling all three states). **The verification claim is the unsupported part**, and *"adapt seamlessly without sacrificing legibility"* is an aesthetic statement rather than a contrast measurement. `[INFERENCE]` **Dark mode multiplies the contrast test matrix exactly the way per-breakpoint styling does** — the Ollie finding from earlier in this batch — and in both cases nothing in the tooling checks the non-default state. **Both belong in the Accessibility Lab plugin's real-time validator.** **And the one the post won't say about itself.** `[INFERENCE]` Cloudflare's Customer Zero policy — *"the burden of proof is on you if you want to use an external vendor… are those 'gaps' true requirements?"* — **produced both the success and the scheduled-post failures described here.** Scheduling, the single most consequential function of a publishing CMS, **broke twice: before launch and again during Agents Week.** The piece reports both honestly and reads the policy exclusively as vindication. **A dogfooding mandate needs a stated threshold at which "use the vendor" is the right answer, and this one doesn't have one.** **Practical next steps.** 1. Adopt **proxy + version cookie + automatic 5xx fallback + percentage ramp** for any migration you run. 2. **Define load-test thresholds before running the test**, and copy the quoted k6 shape. 3. **Check contrast in both themes** — and treat a conformance claim with no named standard as an unverified claim. 4. `[INFERENCE]` Before copying any reference architecture, **check whether it contains a component built for its author.** This one says so in a single clause and most do not say at all. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Cloudflare Blog – Brought to You by EmDash.md|The Cloudflare Blog – Brought to You by EmDash by Cloudflare Blog]] ## Highlights - This is a very real cultural value at Cloudflare. The burden of proof is on you if you want to use an external vendor. Why can’t that team support you, what gaps are there, why can’t those gaps be filled, and are those “gaps” true requirements? ([View Highlight](https://read.readwise.io/read/01m12rpv7s9jfasr9rxbzn6fc1)) - Note: THIS POST IS BOTH THE BEST CASE FOR THIS POLICY AND THE CLEAREST DOCUMENTATION OF ITS COST, AND IT READS IT ONLY AS THE FIRST. THE TELL IS THE LAST CLAUSE: "are those 'gaps' TRUE requirements?" — scare quotes around gaps, burden on the REQUESTER to justify their own requirements. Applied consistently, that routes teams onto internal tooling that doesn't yet do what they need. NOT HYPOTHETICAL — IT'S WHAT THIS POST DESCRIBES HAPPENING. They put a PRE-1.0 CMS on a property that spikes past 5,000 RPS, and SCHEDULED POSTS — the single most consequential function of a publishing CMS — BROKE TWICE. Once before launch ("didn't work until EmDash version 0.19.0… definitely something we didn't want to be finding out after the scheduled time for a post") and AGAIN during Agents Week ("we also found some bugs specifically around scheduled posts"). THE BENEFITS ARE REAL AND STATED — "if a product breaks, it breaks us first. This forces us to fix issues immediately" — AND SO IS THE PRICE. The honest version is a TRADE-OFF WITH A THRESHOLD, and "are those gaps true requirements?" is a question that can always be answered yes. ANY DOGFOODING MANDATE NEEDS A STATED EXIT CONDITION: what would have made "use an external vendor" the right answer here? The policy is stated; the threshold never is. STRUCTURAL NOTE CONNECTING TO THE DRIES THREAD THIS BATCH: aggressive dogfooding is only a virtue when the breaker and the bearer are the same party. Cloudflare owns every layer — benefit, cost and decision authority COLLAPSE INTO ONE ORG. That's the degenerate case of the three-way separation Dries describes, and it's why this is available to them and not to a federated ecosystem. #atom/zettel/z3 - A major priority for this redesign, and a long-overdue request from our readers, was native support for light and dark modes. We implemented theme switching tied directly to system preferences, alongside an explicit toggle, and ensured that accessibility guidelines were strictly met across both themes. Regardless of preference, the updated palette and code syntax highlighting adapt seamlessly without sacrificing legibility. ([View Highlight](https://read.readwise.io/read/01m12rpayphge1ckf3cx2sdt4f)) - Note: THE IMPLEMENTATION PATTERN IS RIGHT; THE CONFORMANCE CLAIM IS UNSUPPORTED. "System preferences, alongside an explicit toggle" is the correct THREE-STATE handling — explicit light, explicit dark, and system default — which is exactly what block themes and artifact pages need and what most implementations get wrong by treating it as a binary. BUT "ENSURED THAT ACCESSIBILITY GUIDELINES WERE STRICTLY MET" NAMES NO STANDARD, NO LEVEL, NO CRITERION, NO AUDIT, NO TOOLING. "Strictly met" is a strong claim with zero evidence attached, and it's phrased to invite trust rather than verification. And "adapt seamlessly without sacrificing legibility" is an AESTHETIC claim, not a contrast measurement. THE SPECIFIC RISK IS WELL KNOWN AND UNADDRESSED: A PALETTE THAT PASSES 1.4.3 IN ONE THEME CAN FAIL IN THE OTHER, and SYNTAX HIGHLIGHTING IS THE USUAL CASUALTY because token colours are tuned against one background. DARK MODE MULTIPLIES THE CONTRAST TEST MATRIX EXACTLY THE WAY PER-BREAKPOINT STYLING DOES — the Ollie/WP 7.1 finding from earlier in this batch. Both are NON-DEFAULT STATES THAT NOTHING IN THE TOOLING CHECKS, and both belong in the Accessibility Lab plugin's real-time validator. A shared test harness would cover both. THE FIX HERE IS ONE SENTENCE: name WCAG and a level. A conformance claim without a criterion means nothing, and this is the pattern to warn against in documentation guidance. #atom/zettel/z2 #action/h2 - To achieve this, we deployed a proxy Worker to intelligently route traffic between the legacy blog and the new EmDash-powered site. This Worker set a version cookie on requests, which then let us route incoming traffic to the new or legacy experience accordingly. Additionally, this strategy allowed us to fall back to the legacy blog if the new site experienced any 500 errors. ([View Highlight](https://read.readwise.io/read/01m12rnv5tcp2g3ac1bjq3bb99)) - Note: THE PATTERN TO STEAL, AND THE THIRD ELEMENT IS THE ONE MOST TEAMS SKIP. Four decisions: (1) a PROXY in front of BOTH systems, so the migration is a routing change rather than a cutover; (2) a VERSION COOKIE, so a reader stays on one experience instead of flapping between two; (3) AUTOMATIC FALLBACK ON 5xx; (4) a percentage ramp — 1% → 5% → 15% → 100% across launch day, gated on validated health. THE FALLBACK IS LOAD-BEARING: A STAGED ROLLOUT THAT CANNOT REVERSE ITSELF WITHOUT A HUMAN IS JUST A SLOWER WAY TO HAVE THE SAME OUTAGE. Everything here except the service binding (NEW_BLOG, worker-to-worker, avoiding "a public hostname, DNS, TLS, and an outbound HTTP connection") is PLATFORM-AGNOSTIC — any stack with a reverse proxy can do proxy + cookie + fallback + ramp. AND IT WORKED AS DESIGNED: "This phased approach allowed us to observe how the platform handled real-world production load while catching a few last-minute edge cases without impacting the vast majority of our audience." PAIRS WITH THE OTHER REUSABLE ARTIFACT IN THIS POST — the k6 config quoted IN FULL, with failure defined BEFORE the runs: >0.01% 5xx, p95 >500ms, p99 >1000ms, checks <0.99. DECIDING WHAT FAILURE MEANS IN ADVANCE IS WHAT MAKES IT A TEST RATHER THAN A DEMONSTRATION. Same principle as requiring a negative control before accepting a detector. Note the proxy Worker itself is DESCRIBED BUT NOT SHOWN — the more valuable of the two patterns is the one without a code sample. #atom/zettel/z1 #action/h1