Blog

When the R2 post arrived the next afternoon

2026-11-04

Cloudflare created incident dr9s0uvzwk6n at 14:43 UTC on 4 November 2026, already resolved. The body dates an R2 window in Western North America to 13:00 through 22:15 UTC on 3 November. The ID was not on the page during that window.

At 20:00 UTC on 3 November 2026, Cloudflare incident dr9s0uvzwk6n was not on the status page. The incident JSON records created_at as 14:43:39 UTC on 4 November. That is the insert. The only update is status resolved, its display_at is 22:15:00 UTC on 3 November, and that update's own created_at is the same 14:43:39 stamp. A customer note written at 20:00 that says the page has no R2 incident in Western North America is describing the page that was up. It is not describing the page Cloudflare published the next afternoon.

One update, and the clocks do not agree

dr9s0uvzwk6n is impact minor. The name is Increased Latency and Errors for R2 and Downstream Services in Western North America (WNAM). The body says Cloudflare has resolved an issue affecting R2 and downstream services in that region, that some customers may have seen elevated latency and errors between approximately 13:00 and 22:15 UTC on 3 November 2026, and that this may also have affected Stream and Pipelines. Cloudflare's component text calls R2 storage for files and objects, Stream a video API, and Pipelines a path that delivers events to R2. A slow object read, a video request, and a pipeline write are three products. The post names all three in one sentence and does not say which customers, which buckets, or what the error rate was.

• started_at is 13:00:00 UTC on 3 November. That is the beginning of the window in the body. 14:43:39 UTC on 4 November is 25 hours 43 minutes 39 seconds later.
• resolved_at is 22:15:00 UTC on 3 November. display_at on the only update is the same minute. Cloudflare's history index dates the line to that minute, so the row sorts onto 3 November even though created_at is the next afternoon. 14:43:39 is 16 hours 28 minutes 39 seconds after 22:15:00.
• There is no investigating update, no identified update, and no monitoring update. The rendered timeline is one resolved line.

Directories keep different clocks from the same JSON. PingView files the ID at 14:43 UTC on 4 November and prints resolved in 0 minutes. OutageDB starts it at 13:00 UTC on 3 November and gives it 9 hours 15 minutes, which is started_at through the end of the body, and does not show created_at. Pulsetic starts the card at 2:43 PM on 4 November, resolves it at 10:15 PM on 3 November, and prints 16 hours 28 minutes. The Pulsetic page does not label the zone. Those faces match created_at and display_at when both are read in UTC, and 16 hours 28 minutes is the gap between the stamp and the insert, with the trailing 39 seconds dropped. Three lengths. None of them is a probe of a bucket. Cloudflare has not posted a cause. Do not fill that gap.

The resolved update moves the components the wrong way

On that same update, affected_components moves R2, Stream, and Pipelines from operational to degraded_performance. The component objects on the same JSON are operational, and their updated_at is 14:43:39 UTC on 4 November. A parser that treats the update's new_status as the state after the sentence marks three products degraded on a resolved incident. A parser that reads only the component object marks them operational and loses the window. The status value resolved and the field new_status are not the same fact.

What was on the page at 18:00

At 18:00 UTC on 3 November the R2 record still did not exist. Incident nbyxn84kvb6o, Cloudflare Workers and Pages build errors, had been open since 14:46:56 UTC. Impact minor. The investigating update says Cloudflare is investigating Workers and Pages build failures that potentially affect multiple customers, and it moves Workers Builds from operational to degraded_performance. Cloudflare describes Workers Builds as the system that deploys a push to a selected branch from GitHub or GitLab. At 15:15 the body says customers may see increased queue times for Workers Builders. At 17:23 the body says queue times are returning to normal and that customers with failed builds can retry from the dashboard or by pushing a new commit. Resolved is 19:38:09 UTC. R2 is not a component on this ID. Retrying a build does not read an object in Western North America.

Incident 7gixemnw9oei is the one that was posted while it was open. Durable Objects in Dallas. created_at is 15:38:17 UTC on 3 November, the same minute as the investigating update. The body says Cloudflare is investigating an increased number of errors from Durable Objects in Dallas, Texas. The component move is Durable Objects from operational to degraded_performance. Monitoring is 16:13, body unchanged beyond saying they are monitoring. Resolved is 16:42:01. Impact minor. Later updates do not carry a component array. The component object is operational, with updated_at equal to the resolved stamp. Host-Tracker times this ID from 15:38 to 16:42 UTC, 1 hour 4 minutes, and says its checkpoints of cloudflare.com recorded no outage of 5 minutes or longer during it. That is what a check of the marketing host can miss, on an incident the status page did publish in time.

Pages upload is the same shape, over nine days

Incident me060q7dbayp was created at 07:11:09 UTC on 4 November. It also has one update. display_at is 06:35:00 UTC on 4 November. started_at is 00:00:00 UTC on 26 October. The body says that between 2026/10/26 and 2026/11/4, some customers trying to upload static Pages assets from the Cloudflare dashboard may have had trouble creating a Pages project. Impact minor. From started_at to display_at is 9 days 6 hours 35 minutes. The affected_components array on that resolved update moves Dashboard from operational to major_outage and Pages from operational to degraded_performance. The component objects are operational. The body does not say the dashboard was in a major outage for nine days. The field does. Do not promote the field into a sentence the body did not write.

Host-Tracker times this ID as 1 minute, 07:11 to 07:11 UTC on 4 November, quotes the body that names 26 October through 4 November, and then says its cloudflare.com checkpoints recorded no outage of 5 minutes or longer during this incident. The check window is the minute they assigned, not the dates in the body. Pulsetic's related card lists the Pages incident as 36 minutes, the gap from display_at 06:35 to created_at 07:11. PingView files it at 07:11 UTC on 4 November and prints resolved in 0 minutes. A duration picked off a directory is not the set of projects that failed to create.

Copy you can adapt

The weak version matches the page a person could see at 20:00 UTC on 3 November, and it does not survive the insert:

Checked Cloudflare at 20:00 UTC on 3 November. No R2 incident. Workers builds are in monitoring and the note says to retry a failed build. The bucket errors in WNAM are ours.

That note costs the window the page had not published yet. At 14:50 UTC on 4 November the same status page says R2 in Western North America, and possibly Stream and Pipelines, may have been slow or erroring from about 13:00 to 22:15 UTC on 3 November. The 20:00 note is now the sentence that tells the next person not to open the bucket logs. It also names the wrong product. Workers Builds was the component on nbyxn84kvb6o. R2 was not on that ID. Someone who forwards the weak paragraph sends the team to a retry button for builds, and the object errors stay in the application logs.

A note that keeps the insert time:

14:50 UTC, 4 November. Cloudflare incident dr9s0uvzwk6n was created at 14:43:39 UTC today. One update, status resolved, display_at 22:15 UTC on 3 November. started_at 13:00 UTC on 3 November. Impact minor. The body says some customers may have seen elevated latency and errors on R2 in Western North America between about 13:00 and 22:15 UTC on 3 November, and that Stream and Pipelines may have been affected. On that update the component delta moves those three from operational to degraded_performance. The component objects are operational. There was no post during the window. At 18:00 UTC on 3 November the open ID was nbyxn84kvb6o, Workers Builds, which does not list R2. Cloudflare has not posted a cause. Do not tell the customer the 20:00 check cleared storage.

What not to do

• Do not treat a resolved stamp as the time the page told you. On dr9s0uvzwk6n the stamp is 22:15 UTC on 3 November and the row was created at 14:43:39 UTC on 4 November.
• Do not pick a directory duration and call it the impact. PingView says 0 minutes, OutageDB says 9 hours 15 minutes, Pulsetic says 16 hours 28 minutes.
• Do not read new_status on the resolved update as the state after resolution. On this ID it is degraded_performance while the component object is operational.
• Do not explain WNAM object errors with the Workers Builds incident. nbyxn84kvb6o does not list R2.
• Do not turn the Pages field major_outage into a claim that the dashboard was down from 26 October. The body says some customers may have had trouble creating a Pages project.
• Do not invent a cause. Neither resolved line has one.

Operator checklist

1. Write created_at next to display_at. If the row is newer than the window, the window was not on the page while it was open.
2. Read affected_components and the component object. On a one-update incident they can disagree.
3. Keep the product. Workers Builds, Durable Objects in Dallas, R2 in WNAM, and Pages uploads are different IDs.
4. If a directory prints 0 minutes, open the JSON before you tell anyone the blip was too short to matter.
5. Leave the cause blank until Cloudflare writes it.

For the host we measure, /status/cloudflare at 19:10 UTC on 4 November showed the service host reachable and the vendor column as outage, with no probe incidents from 28 October 19:10 UTC to 4 November 19:10 UTC, and probe p50 about 126ms. At 19:28 UTC the same evening, Cloudflare's status.json had indicator major and the description Partial System Outage. That top-level indicator is what the vendor column is reading. R2 on dr9s0uvzwk6n is operational, so the column is not this WNAM window. Reachable means the host answered. It does not GET an object from R2, upload a Pages project, or open a Durable Object in Dallas. The same two columns for other hosts are on /status. A monitoring line that was walked back on a different Cloudflare incident is the 16:27 monitoring post. Copy the ID, the created_at, and the component. The 22:15 stamp is when the backdated line says the window ended.