DEV Community: ushiro

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

ushiro — Tue, 01 Sep 2026 12:00:00 +0000

Every page on my site declared export const revalidate = 300. Nine locales served from ISR.
The tenth — the one that is actually canonical, the one crawlers hit most — re-rendered from scratch
on every single request for weeks.

The difference between them was not a page, a config flag, or a deployment. It was that the tenth
locale's URL went through a NextResponse.rewrite() in middleware.ts.

I run AI Change Watch, a Next.js App Router site on Cloudflare
Workers (via OpenNext) that crawls what AI vendors publish about their own models and records every
change. en is served unprefixed (/deprecations), the other nine locales are prefixed
(/ja/deprecations). That unprefixed mapping was one line of middleware.

What the headers said

Measured on production, 2026-08-06. Same page, same component tree, same revalidate = 300 — only
the routing path differs:

/bot, /rankings                (rewritten in middleware)
  Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
  (no x-nextjs-* headers at all)

/ja/bot, /ja/rankings          (passed through with next())
  Cache-Control: s-maxage=300, stale-while-revalidate=...
  x-nextjs-prerender: 1

private, no-store on a page whose whole point is to be cached. And not "cached badly" — there are
no x-nextjs-* headers on those responses whatsoever, which means Next never treated the request as
a route that has an incremental cache entry. Nothing was written, so nothing could ever be read.

Why this hides so well

Three things kept this invisible for weeks, and I think each one is general.

The prefixed locales are fine. Any "is my ISR working?" check you run against /ja/... passes.
The bug is per-path, and it only touches the paths middleware rewrote.

Probing the prefixed form of the broken URL measures nothing. /en/bot 307-redirects to the
canonical /bot (verified again today), so curl -I /en/bot returns a redirect and tells you
nothing about the page. You have to test the unprefixed URL. I burned an eight-minute polling
loop on /en/bot before noticing that.

Pages still refresh, so content never looks stale. Deploys change the buildId, the buildId is part
of the cache key space, and this repo deploys several times a day — so the whole cache was being
invalidated often enough that no page was ever visibly out of date. revalidate = 300 was decorative,
and deployment frequency was covering for it. (There was a second, independent reason revalidation
never ran on this stack; that one is
its own post.)

The cause

This is vercel/next.js#83862 — "SWR Cache-Control
disabled after Next.js 15.5 when using a rewrite middleware", open, filed 2025-09-16, reported
against 15.4.2-canary.2 through 15.5.3. I reproduce it on 15.5.21.

The explanation in the issue is that Next matches the pre-rewrite path against the
dynamic-route regexes. /bot matches nothing (the real route is app/[locale]/[provider]/page.tsx),
so the response falls back to the private, no-store default. That mechanism is upstream's account
and the internals are not something I can observe from outside; what I can state is the header pair
above, and that it flips based solely on whether the rewrite happened in middleware.

The important consequence is that it is a write-side failure, not a read-side one. No entry is
ever created for those keys. So nothing that improves cache lookup can help.

Two things that did not fix it

Rewriting the rewrite. There is no shape of NextResponse.rewrite() that avoids this. It is not
a matcher problem or an ordering problem.

Serving ISR from the adapter's routing layer (OpenNext's enableCacheInterception: true) looked
like the perfect workaround: resolve the cache before NextServer is ever invoked, and the pre-rewrite
path matching stops mattering. Cache hits did work — I have x-opennext-cache: HIT on prefixed
locales to prove it. It still could not fix English, because the cache was empty for those keys, and
then it took the site down:

Error in routingHandler
  at Object.send (worker.js:116290)     at computeCacheControl (worker.js:120329)
  at generateResult (worker.js:120394)  at cacheInterceptor (worker.js:121493)

On a stale entry the interceptor has to dispatch the background re-render itself, and at that
point I had no revalidation queue bound. Inside NextServer that same failure is caught and logged as
a warning. In the routing layer it wasn't caught, so the request returned 500. Two properties made it
much worse than an ordinary bug: it threw before the render, so the entry could never refresh and
the 500 was permanent per URL; and it only fired once an entry passed its revalidate window, so
pages died one at a time over several hours — 12 URLs before I reverted it.

If you take one thing from this post, take that shape: a failure that is caught in one layer and
uncaught in the layer you moved it to.

The fix

Move the rewrite out of middleware and into next.config.mjs. A config rewrite lands in the routes
manifest, which the adapter's routing layer applies to the internal request, so NextServer receives a
plain /en/... request with no x-middleware-rewrite header — the exact path /ja/... always took.

async rewrites() {
  const reserved = 'en|ja|zh|es|de|fr|ko|pt|it|tr|api|_next|sitemaps';
  return {
    afterFiles: [
      { source: '/', destination: '/en' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)`, destination: '/en/:seg' },
      { source: `/:seg((?!(?:${reserved})(?:/|$))[^/]+)/:rest*`, destination: '/en/:seg/:rest*' },
    ],
  };
}

Middleware keeps the /en/... → /... redirect. Redirects are unaffected; only rewrites are.

afterFiles, not beforeFiles. afterFiles runs only when no real route matched, so
/sitemap.xml, /robots.txt, /icon.svg and friends resolve as themselves before this pattern is
consulted, and drop out of the exclusion list for free. With beforeFiles every one of them needs an
explicit exclusion, and each missing exclusion is a 404 on a canonical URL.

The exclusion regex has two traps

Both of these produce a config that builds fine and 404s in production.

Trap 1: anchor each alternative to a segment boundary. The negative lookahead has to end with
(?:/|$), not $. With $ alone it only fires when the reserved word ends the path:

                 $ only                    (?:/|$)
/bot          -> /en/bot                 -> /en/bot
/ja/bot       -> /en/ja/bot   ← 404      -> (no rewrite)  ✓
/en/bot       -> /en/en/bot   ← 404      -> (no rewrite)  ✓
/api/contact  -> /en/api/contact ← 404   -> (no rewrite)  ✓
/sitemaps/1   -> /en/sitemaps/1 ← 404    -> (no rewrite)  ✓

That table is RegExp.exec output, not a sketch. It is also the same family of bug as writing bare
api in a matcher, which swallows /api-features — a page of mine that 404'd on its canonical URL
for exactly that reason.

Trap 2: root-level dynamic routes are not protected. The "real routes win first" property of
afterFiles is gated on the adapter's static route matcher. /sitemaps/[id] is root-level and
dynamic, so it is not covered, and it has to be named in reserved by hand. If you add a root-level
dynamic route later, it needs the same entry — there is nothing to remind you.

How to check it, in the order that actually works

1. Test the compiled regex, not the source string. What runs is the pattern Next compiles into
.next/routes-manifest.json, and it is not what you typed. Build to a scratch directory
(NEXT_DIST_DIR=.next-rwtest next build), read the manifest, and assert every URL class you care
about — locale-prefixed, /en/-prefixed, /api/*, /_next/*, root-level files, root-level dynamic
routes, the feeds. All four shadowing bugs above were caught this way before deploying, and none of
them was visible in the source.

2. Then check the unprefixed URL on production. Today, on the same pages, 2026-08-27:

$ curl -sI https://aichangewatch.com/bot | grep -i 'cache\|nextjs'
Cache-Control: s-maxage=3600, stale-while-revalidate=31532400
x-nextjs-cache: STALE
x-nextjs-prerender: 1
x-nextjs-stale-time: 300

$ curl -sI https://aichangewatch.com/deprecations | grep -i 'nextjs'
x-nextjs-cache: HIT
x-nextjs-prerender: 1

x-nextjs-prerender: 1 is the header that was absent before, and it is the one to look for.
x-nextjs-cache: MISS on its own proves nothing — that is the earlier post's subject.

What I still haven't proven

Whether this reproduces off this adapter. Every measurement here is Next 15.5.21 + @opennextjs/cloudflare on Cloudflare Workers. The upstream issue is not adapter-specific and the reporters were not on my stack, but I have not tested Vercel or a plain next start myself.
Why the no-store fallback is chosen. I am quoting the issue's explanation of the path matching, not something I read out of the runtime.
The 500 attribution. That the interceptor threw at Object.send before the render is read off the stack trace and the fact that the 500s stopped on revert. I did not instrument it.

If you serve a default locale unprefixed on App Router, the check is one command and the failing case
looks completely healthy: full-SSR responses are correct, just uncached. Test the URL your users get,
not the internal one.

The site this came out of is AI Change Watch — vendor deprecation
tables, pricing and SDK changelogs, diffed on a schedule. The pages in the measurements above are
real ones; /deprecations is the one with the highest cache-hit value, which is why it was the first
thing I noticed serving no-store.

The iCalendar Spec Says 75 Octets, Not 75 Characters

ushiro — Thu, 27 Aug 2026 12:00:00 +0000

I run AI Change Watch, a small independent project that
crawls what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing
and SDK releases — and records every time one of them changes.

One of the things it publishes is a subscribable calendar: every announced model shutdown, as .ics,
so a date the vendor moves updates in your calendar instead of in a changelog you forgot to read.

The English feed worked immediately. The Japanese one was rejected.

Same code. Same events. The only difference was the language of the text inside.

The line that RFC 5545 actually specifies

Section 3.1:

Lines of text SHOULD NOT be longer than 75 octets, excluding the line break.

Not 75 characters. 75 octets.

For ASCII those are the same number, which is exactly why this survives every test you are likely to
write. SUMMARY:gpt-4-32k shutdown (OpenAI) is 36 characters and 36 bytes. Nothing to notice.

Then the same field comes back translated:

SUMMARY:code-davinci-001 提供終了（OpenAI）

That is 30 characters. It is 49 octets — Japanese runs about 3 bytes per character in UTF-8. A
folder that counts characters looks at 30, decides no fold is needed, and emits a line that is legal by
its own arithmetic and illegal by the spec's.

Longer titles cross 75 octets while still well under 75 characters, and that is the line the parser
rejects.

Why counting characters isn't the only bug

The obvious fix — count bytes instead — introduces a second one if you write it the obvious way.

// Still broken.
const bytes = Buffer.from(line, 'utf8');
for (let i = 0; i < bytes.length; i += 75) {
  out.push(bytes.subarray(i, i + 75).toString('utf8'));
}

Slicing a UTF-8 buffer at a fixed offset cuts through the middle of a character. Byte 75 lands in
the second of the three bytes that make up 終, and you emit half a codepoint on one line and the other
half on the next. Some parsers replace it with U+FFFD, some abort the file.

So the fold has to be counted in bytes but taken at character boundaries:

export function foldLine(line) {
  const enc = new TextEncoder();
  if (enc.encode(line).length <= 75) return line;

  const out = [];
  let cur = '', curBytes = 0;
  // The first line gets 75 octets; every continuation gets 74, because the leading
  // space that marks it as a continuation counts toward the limit too.
  let limit = 75;

  for (const ch of line) {          // iterating a string yields whole codepoints
    const n = enc.encode(ch).length;
    if (curBytes + n > limit) {
      out.push(cur);
      cur = ''; curBytes = 0; limit = 74;
    }
    cur += ch;
    curBytes += n;
  }
  if (cur) out.push(cur);

  return out.map((l, i) => (i === 0 ? l : ` ${l}`)).join('\r\n');
}

Three things in there are easy to leave out and each one produces a file that mostly works:

for (const ch of line), not line[i]. Indexing a JS string walks UTF-16 code units, so an emoji
or any astral-plane character gets split at the surrogate pair. Iterating with for...of yields whole
codepoints.

The limit drops from 75 to 74 after the first line. The continuation marker is a single leading
space and it counts. Keep the limit at 75 and every folded line is one octet over — which is the same
bug you just fixed, only harder to see because it only shows up on lines long enough to fold.

\r\n, not \n. RFC 5545 wants CRLF. Plenty of parsers tolerate bare LF, right up until one
doesn't.

The other one: your UID is not a display string

An .ics feed served in ten languages raises a question the spec answers but does not warn you about:
what is the UID?

If you build it from the localized summary, the same shutdown gets a different UID in every language.
Subscribe to two of them and your calendar shows two entries for one event, forever, with no way to
tell they are the same thing.

So the UID has to be keyed on the entity, never the presentation:

UID:shutdown-o1-preview@aichangewatch.com
UID:shutdown-davinci-002@aichangewatch.com

Model slug, no locale. I checked the two live feeds while writing this:

en feed:  262 UIDs
ja feed:  262 UIDs
shared:   262            ← identical sets

Which means a person subscribed to both gets one entry per shutdown, not two. The second subscription
overwrites the first rather than duplicating it. That is the correct failure mode — a collision beats
a double-booking, because a duplicate calendar entry is something the user has to notice and clean up by
hand.

It also means you cannot use the UID to carry the language. If you need that, it belongs in the calendar
name (X-WR-CALNAME), not the identity.

What I check now

The whole class is "a spec said octets and I read characters", and it is worth one assertion in a test
rather than a careful reading:

const body = renderCalendar(events);
for (const line of body.split('\r\n')) {
  expect(Buffer.byteLength(line, 'utf8')).toBeLessThanOrEqual(75);
}

Run it against the localized feed, not the English one. The English feed cannot fail this test,
which is precisely why it is not the one to run it on. Mine currently reports:

en feed:  6,545 lines,   0 over 75 octets,  506 continuation lines
ja feed:  6,606 lines,   0 over 75 octets,  567 continuation lines

The 61 extra lines in the Japanese feed are the folds the English one does not need. That gap is the
bug, made visible: same events, same code, more lines — because the same sentences take more bytes.

The tracker this came out of is at aichangewatch.com — the
shutdown calendar it generates is at
/deprecations/calendar.ics.

`next dev` Renders but Nothing Works: Your CSP Is Missing `unsafe-eval`

ushiro — Mon, 24 Aug 2026 12:00:00 +0000

At some point I added a Content-Security-Policy. It was correct. It shipped. Production was fine.

And then, locally, every interactive thing on the site stopped working.

The symptom

next dev starts. The page loads. It looks exactly right — the layout, the data, the styles, all
of it. Then:

the search box accepts text and filters nothing
the sort headers don't sort
the "show more" button does nothing
no onClick anywhere fires

No error page. No red overlay. No failed request in the Network tab. The server rendered the HTML and
sent it, so the page you are looking at is real — it is just completely inert. Nothing hydrated.

If you have not hit this before, the natural first guess is your own component. That is where I went,
and it is the wrong place, because every component is fine.

The one line that names it

The console has it, but you have to be looking:

Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an
allowed source of script in the following Content Security Policy directive:
"script-src 'self' 'unsafe-inline' …"

And the reason it is easy to miss is that it is not a JavaScript error. It does not have a stack. It
does not point at your file. It appears once, near the top, above whatever else the page logged, and it
names a directive rather than a component.

Why this happens in dev and not in prod

Next's development server compiles modules and hands them to the browser wrapped in eval — that is
how the dev devtool setting works, and it is what React Refresh needs to swap a component without
reloading the page. Fast Refresh is built on it.

A production build does not do that. next build emits static chunks. There is no string being
evaluated at runtime, so there is nothing for 'unsafe-eval' to permit.

Which produces the trap:

The CSP is correct for production and fatal in development — and development is where you spend all
your time.

You will not catch it in CI, because CI builds. You will not catch it in preview, because preview
builds. You catch it the moment you try to click something locally, and by then you are three commits
into a feature and looking for the bug in your own diff.

Why the header reaches dev at all

Because it is in next.config, and that file has no idea which mode it is running in unless you tell
it:

// next.config.mjs
async headers() {
  return [{ source: '/:path*', headers: securityHeaders }];
},

source: '/:path*' means every path. There is no dev/prod branch, so next dev serves the same header
next start does. That is a reasonable default — you generally want to develop against the headers
you ship — it just happens to be wrong for this one directive.

Two fixes, and they are not equivalent

Option A — widen the policy in development only.

const isDev = process.env.NODE_ENV === 'development';

const csp = [
  "default-src 'self'",
  // 'unsafe-eval' is DEV-ONLY: the dev server evaluates compiled modules as strings (that is what
  // React Refresh is built on), and a production build never does. Shipping it would be a real
  // widening of the policy for zero benefit.
  `script-src 'self' 'unsafe-inline'${isDev ? " 'unsafe-eval'" : ''}`,
  // The HMR socket, same reasoning. In production nothing connects back to the dev server.
  `connect-src 'self'${isDev ? ' ws: wss:' : ''}`,
  // …the rest
].join('; ');

The comment is not decoration. A conditional in a security header is exactly the kind of line that gets
"cleaned up" six months later by someone who reads it as an inconsistency, so the reason it is
conditional has to sit next to it.

Option B — stop testing client behaviour in next dev.

next build && next start

This is what I actually do, for a reason that has nothing to do with CSP: this project deploys to
Cloudflare Workers through OpenNext, and next dev is not the runtime it ships on. Behaviour I verify
in dev is behaviour I verified somewhere the code will never run. So for anything client-side I build
and serve the real thing.

The cost is real — you lose Fast Refresh, and a rebuild per change is slow enough to change how you
work. If your production runtime is Node, Option A is the better trade. If it isn't, Option B was
going to be necessary anyway and this just makes it obvious sooner.

The general shape

The thing worth taking away isn't the directive. It's this:

A security header set in next.config applies to the dev server, and the dev server has different
requirements than the thing you deploy.

unsafe-eval is the one that produces a silent failure, which is why it costs the most time. But the
same category catches you elsewhere:

directive	what dev needs that prod doesn't
`script-src`	`'unsafe-eval'` for the module runtime / React Refresh
`connect-src`	`ws:` / `wss:` for the HMR socket
`style-src`	`'unsafe-inline'` if your prod build extracts CSS but dev injects it

If you are about to add a CSP to a Next app, the fastest check is not a code review. It is:

next dev
open the page
click something
read the console — the first line, not the last

Thirty seconds, and it is the only test that distinguishes "rendered" from "working". Everything else
about a dead page looks identical to a live one.

The tracker this came out of is at aichangewatch.com — it watches AI
vendor docs for changes. Its CSP still has no 'unsafe-eval' in production, which is the point.

Your Worker Returned 500 and the Log Says `outcome: "ok"`

ushiro — Fri, 21 Aug 2026 12:00:00 +0000

It runs on Cloudflare Workers, which means that when someone tells me "your site 500'd an hour ago",
the obvious tool is useless. wrangler tail is a live stream. It shows you what is happening now.
It cannot show you an hour ago.

There is a way to read the past, and there are four traps in it that cost me most of a day.

The part that works

Workers can write their invocation logs to a queryable store, and a REST endpoint reads it back. First
the worker has to be opted in — this is the whole config:

// wrangler.jsonc
{
  "observability": { "enabled": true }
}

Then you can ask for events in a time range:

curl -sX POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT/workers/observability/telemetry/query" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "queryId": "anything",
    "timeframe": { "from": 1786000000000, "to": 1786003600000 },
    "limit": 500,
    "view": "events",
    "parameters": {
      "datasets": ["cloudflare-workers"],
      "filters": [
        { "id": "f1", "key": "$workers.event.response.status",
          "type": "number", "operation": "eq", "value": 500 }
      ]
    }
  }'

from and to are epoch milliseconds, not ISO strings. A read-scoped API token is enough — the
one I already had for deploys worked unchanged.

Each event carries more than you would guess:

$workers.outcome                              ok | exceededCpu | canceled
$workers.cpuTimeMs  /  $workers.wallTimeMs
$workers.event.request.path  /  .search
$workers.event.request.headers['user-agent']
$workers.event.request.cf.asOrganization      the ASN owner
$workers.event.response.status
$metadata.error

That is the tool. Now the traps.

Trap 1: a rendered 500 is a successful invocation

I started by filtering on the field that sounds right:

{ "key": "$workers.outcome", "operation": "eq", "value": "exceededCpu" }

and found nothing, repeatedly, while the site was demonstrably returning 500s.

Because for every one of them:

$workers.outcome = "ok"

The worker ran. It produced a response. It returned it. That the response was an error page is not the
runtime's problem — the invocation succeeded. outcome describes the worker, not the HTTP result.

So outcome is the wrong axis for application errors. Filter on $workers.event.response.status for
what the user saw, and read $metadata.error for the throw. outcome is for failures the runtime
itself noticed: CPU limit, cancellation.

This is worth internalising because it inverts the usual relationship. In most stacks "the request
failed" and "the handler failed" are the same event. At the edge they are two different fields — and
the one with the friendlier name is the one that will not tell you.

Trap 2: a wide time window silently undercounts

This is the one that actually cost me the day.

I asked for 5xx across a 24-hour window, got nine events, and concluded I was chasing a single bug. The
same 24 hours, walked in 4-hour slices and concatenated, returned 956 — across 92 URLs and three
unrelated causes.

I re-ran the comparison today, on 404s, to check it was not a one-off:

24h asked as one query      →  26 events
same 24h in 4h slices       → 266 events

The single query returned 10% of what was there. Not a rounding difference — a different
conclusion. And nothing in the response says so: no truncation flag, no "results were sampled" field.
You get a well-formed answer that happens to be mostly missing.

So the loop, not the query:

const out = [];
for (let h = 24; h > 0; h -= 4) {
  const from = Date.now() - h * 3600_000;
  const to   = Date.now() - (h - 4) * 3600_000;
  const ev = await queryEvents({ from, to, limit: 500 });
  if (ev.length >= 500) console.warn(`slice ${h}h hit the limit — narrow it`);
  out.push(...ev);
}

The ev.length >= 500 check matters as much as the slicing. A slice that returns exactly your limit is
truncated, and you have to narrow that slice further. Without the warning you cannot tell "500 events
happened" from "500 events fit".

Trap 3: `exists` matches empty strings, and `includes` ignores case

Two smaller ones, both of which produced confidently wrong numbers before I noticed.

operation: "exists" matches a key that is present but empty. I wanted requests Cloudflare had
identified as verified bots:

{ "key": "$workers.event.request.cf.verifiedBotCategory", "operation": "exists" }

That field is present on every request and is "" on almost all of them, so the filter matched the
entire dataset and I briefly believed the whole site was bot traffic. Use exists only for keys
genuinely absent on what you are excluding — sec-fetch-mode is a real example, since non-browsers do
not send it.

operation: "includes" is case-insensitive. Filtering user agents for bot and for Bot returned
the identical 3,181 events. Convenient once you know; misleading if you were using case to separate two
populations.

Trap 4: event counts are not invocation counts

The events view and the dashboard's invocation count disagree, and both are right. On one day my web
worker showed 24,085 telemetry events against 8,772 invocations — roughly 2.7 events per
invocation.

So:

proportions — "what share of requests were 404s", "which UA dominates" — take from the events view
absolute totals — "how many requests did this worker serve" — take from workersInvocationsAdaptive in the GraphQL analytics API, not from counting events

Mixing them gives a number that is wrong by a factor you cannot see.

What I actually run now

// Past-tense debugging: "what 500'd between 3am and 4am".
async function queryEvents({ from, to, limit = 500, filters }) {
  const r = await fetch(
    `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT}/workers/observability/telemetry/query`,
    { method: 'POST',
      headers: { Authorization: `Bearer ${TOKEN}`, 'Content-Type': 'application/json' },
      body: JSON.stringify({
        queryId: 'q', timeframe: { from, to }, limit, view: 'events',
        parameters: { datasets: ['cloudflare-workers'], filters },
      }) });
  const d = await r.json();
  return d?.result?.events?.events ?? [];
}

…called from the slicing loop above, with the results grouped in plain JavaScript rather than by asking
the API to group them. (view: "calculations" with a groupBy on a high-cardinality key returns only a
few groups, quietly — the same failure mode as trap 2: a well-formed answer that is mostly missing.)

The retention window is limited. I have reliably queried three days back and would not build a workflow
that assumes more; for anything you need to keep, pull it out and store it yourself.

One more, learned the embarrassing way: cf.asOrganization is the ASN owner, not the bot. Requests
from "Anthropic, PBC" turned out to be a crawler that robots.txt already allowed, and "Amazon
Technologies" was PerplexityBot. Identify declared crawlers by user agent; use the ASN only to catch
traffic whose user agent is lying.

The one-line version

wrangler tail is for watching. For asking, use the telemetry API — and remember that outcome: "ok"
means the worker succeeded, not that your user did, and that a query covering a wide window will hand
you a confident answer built from a tenth of the data.

The tracker this came out of is at aichangewatch.com — it watches AI
vendor docs for changes, and the 500s that started all this were a REST detail endpoint quietly falling
through to its collection endpoint.

A Missing ID Doesn't 404 — It Fetches the Whole Collection

ushiro — Tue, 18 Aug 2026 12:00:00 +0000

Keeping it running turned up a bug I think a lot of REST clients have and nobody notices, because it
doesn't look like a bug from either side.

Here it is in one line:

GET /v1/events/{id}   with an empty id

becomes

GET /v1/events/

which is not a 404. It's the list endpoint. It returns 200 OK.

What that did to my site

Every change on my site lives at a URL like:

/event/openai-gpt-4-deprecated-bf_20260723143458_0003

Slug for humans, id after the last hyphen for the lookup. The parser is exactly what you'd expect:

export function eventIdFromParam(param: string): string {
  const i = param.lastIndexOf('-');
  return i === -1 ? param : param.slice(i + 1);
}

Now consider /event/google-. A trailing hyphen, no id. Crawlers generate these. So do chat clients and
mail readers that break a long URL across lines and leave the tail behind.

lastIndexOf('-') finds the final character, slice(i + 1) returns "", and the fetch goes out as
/v1/events/.

The API answers 200 with { data: [ …every recent event… ] }.

My mapper then did what mappers do — it mapped:

if (j) return fromApi(j.data);   // j.data is an ARRAY here

fromApi read .title, .providerName, .severity off an array. All undefined. No error yet:
reading a missing property off an array is perfectly legal. The page got an object shaped like an event
whose every field was empty, rendered happily down the tree until it reached:

providerName.charAt(0)

and threw.

So the URL returned 500 where a 404 was owed. /event/google-, /event/aws-,
/ja/event/groq-groq- — all 500, live, for as long as they had existed.

Why it survived so long

Two reasons, and the second is the interesting one.

It is invisible in the request logs. I found this by querying Cloudflare's observability API for
5xx responses, and the field I would naturally have filtered on was useless:

$workers.outcome = "ok"     ← for every single one of them

A rendered 500 is a successful worker invocation. The worker ran, produced a response, returned it.
That the response was an error page is not the worker's problem. The signal lives in
$metadata.error, not in the outcome. If you filter your edge logs by outcome, application-level 500s
are simply not in your dataset.

And a sibling route accidentally hid it. The same data layer serves
/pricing/history/<slug>-<id>, and that route never 500'd. Not because it was written more carefully —
because it happens to filter:

type === 'pricing_changed'

The junk object had type: undefined, so the filter rejected it and the page 404'd correctly.
Entirely by accident.

That made the bug look route-specific. I spent time reading the event page, which was the one place
the defect wasn't.

The actual shape of the problem

It isn't the parser, and it isn't the page. It's this:

A REST detail path with a missing key silently degrades into the collection path.

/things/{id} and /things/ are different endpoints with different response shapes, and the only
thing separating them is a string you built by hand. When that string is empty, the URL you send is a
valid request for something else entirely, and it succeeds.

No status code tells you. Both are 200. Both return { data: … }. The only difference is that one
data is an object and the other is an array — and JavaScript will let you read properties off both.

The fix, and where it goes

Two guards, and it matters that they are in the data layer rather than in the page:

export async function getEvent(id: string): Promise<CWEvent | null> {
  // An empty id is a not-found, not a request.
  if (!id) return null;

  const j = await api<{ data: any }>(`/v1/events/${id}`);

  // Only a DTO that actually carries an id is an event. Anything else — a list payload,
  // `{data:null}` — is not-found, never a half-populated object handed to the renderer.
  if (j?.data?.id) return fromApi(j.data);
  if (j) return null;

  // `j === null` means the API was never reached at all (build time, or local dev with no base URL),
  // which is a different condition from "the API answered and there is no such event".
  return MOCK_EVENTS.find((e) => e.id === id) ?? null;
}

The first guard stops the malformed request being sent. The second stops a wrong-shaped response being
trusted if one arrives anyway. The third line matters for a reason worth stating: "the API said no"
and "I never reached the API" have to stay distinguishable, or a build-time render quietly turns
every page into a 404.

Putting all this in getEvent() rather than in the page component covers three call sites at once: the
page, generateMetadata, and the OpenGraph image route. Fixing it in the component would have left two
of those still 500ing, and OG image failures are especially quiet — nobody notices a missing preview
card until someone shares the link.

All four URLs are 404s now:

/event/google-                404
/event/aws-                   404
/ja/event/groq-groq-          404
/pricing/history/deepseek-    404

How to find this in your own code

The grep that would have found it for me:

# a template literal that interpolates straight into a path segment
grep -rnE '`[^`]*/\$\{[A-Za-z_]+\}`' src/

Then, for each hit, three questions:

Can that value ever be an empty string? Anything derived from a URL segment, a regex capture, a split() or a slice() can be. Mine came from lastIndexOf.
What does your API return for the collection path? If it is a 200 with a different shape, you have this bug waiting. If it 404s or 405s, you don't. This is worth one curl: curl -i https://api.example.com/v1/things/
Does your mapper verify the shape, or just read fields off it? Reading .id off an array returns undefined rather than throwing, so the failure surfaces far away from its cause — in my case several components later, on a .charAt(0).

If you own the API as well as the client, there is a fourth option that fixes it for every consumer at
once: make the collection path reject a trailing slash instead of serving the list. I didn't, because
the list endpoint is a real endpoint that real callers use — but if yours isn't, that's the cheaper fix.

The one-line version: check the id before you build the URL, and check the response carries an id
before you trust it. Neither check is clever. Both were missing.

Found 2026-08-08, fixed the same day. The tracker this came out of is at
aichangewatch.com — it watches AI vendor docs for changes, which is how it
ends up with a lot of URLs that crawlers like to truncate.

Google removed an announced Gemini 2.5 shutdown date with no changelog entry

ushiro — Thu, 13 Aug 2026 12:00:00 +0000

On July 28, Google's Gemini API deprecation page said gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite would shut down on October 16, 2026. By August 3 the date was gone. The rows now read "No shutdown date announced", and the current page shows no sign that October 16 was ever there.

I could not find the change announced anywhere — not in the Gemini API changelog, not in the release notes.

Meanwhile Google Cloud's own lifecycle page still lists all three models with a shutdown date of October 20, 2026 — four days later than the one that disappeared. Both pages are live as I write this, and they give different answers for the same three models.

That is the thread running through everything below: model lifecycle pages are not references you read once, they are data that moves — and comparing them across vendors turned out to be harder than collecting them.

I found this while crawling what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing and SDK releases — and recording every time one of them changes. I had assumed tracking model deprecations would be straightforward: find the vendor's lifecycle page, extract the model name and retirement date, keep it updated.

It wasn't.

Here are some things I found while trying to make the data comparable.

1. A previously announced shutdown date can disappear

On July 28, Google's Gemini API deprecation page listed:

gemini-2.5-pro
gemini-2.5-flash
gemini-2.5-flash-lite

All three had a shutdown date of October 16, 2026, along with replacement models.

On August 3, the entries changed. Here is the gemini-2.5-pro row:

	July 28	August 3
Shutdown date	October 16, 2026	No shutdown date announced
Replacement	`gemini-3.1-pro-preview`	—
Status	deprecated	unknown

The other two rows changed the same way, each losing its own replacement (gemini-3.6-flash for gemini-2.5-flash, gemini-3.1-flash-lite for gemini-2.5-flash-lite).

The current page doesn't show that October 16 was ever announced.

There is no change history and no note saying the date was withdrawn. The only signal is the Last updated stamp at the foot of the page, which moved from 2026-07-30 UTC to 2026-08-03 UTC. It tells you that something changed, not what.

You don't have to take my word for the earlier state — the Internet Archive holds both sides:

August 2 capture (Last updated 2026-07-30 UTC): all three rows read October 16, 2026, each with a replacement.
August 4 capture (Last updated 2026-08-03 UTC): all three read No shutdown date announced, replacement column empty.

In the same table, gemini-2.5-flash-image reads October 2, 2026 in both captures. Three rows changed; the page wasn't rebuilt.

Was the change announced anywhere?

The deprecation page itself says where to look:

Deprecation announcements are made on the Release notes page, and the announced earliest shutdown dates are tracked on this page.

The Gemini API release notes are current — Last updated 2026-08-11, most recent entry July 30 — and mention neither October 16 nor its withdrawal.

There is another place to look. Google serves these same models through Google Cloud as well, where the Vertex AI documentation has moved to Gemini Enterprise Agent Platform. That lifecycle table never withdrew the date. As of August 12 it still reads:

Model	Retirement date
`gemini-2.5-pro`	October 20, 2026
`gemini-2.5-flash`	October 20, 2026
`gemini-2.5-flash-lite`	October 20, 2026

Not October 16. October 20. Archive captures of the two pages put that shift a few days ahead of the withdrawal:

Capture date	Google Cloud	Gemini API
June 10	`Not before October 16, 2026`	`October 16, 2026`
July 18–19	`October 16, 2026`	`October 16, 2026`
July 30	`October 20, 2026`	`October 16, 2026`
August 4 →	`October 20, 2026`	`No shutdown date announced`

So Google Cloud moved the date by four days, and days later the Gemini API page dropped it altogether. I could not find either change announced. The Agent Platform release notes are actively maintained — most recent entry August 4 — and don't mention it. The only announcement of October 16 I found anywhere is an April 2, 2026 entry in the old Vertex AI release notes ("The retirement dates for Gemini 2.5 Pro, Gemini 2.5 Flash-Lite, and Gemini 2.5 Flash have been updated to October 16, 2026") — on a page that now carries the banner "Vertex AI documentation is no longer being updated" and whose most recent entry is May 26.

That leaves two live answers for the same three models. Read the Gemini API docs: no shutdown date. Read Google Cloud: October 20, 2026.

Which is section 1's problem again — two platforms, two lifecycles, each page correct about its own endpoint — except this time it's one vendor. That's a defensible way to run it. It's still two answers, and neither page tells you it isn't the only one.

I noticed this because I had captured the earlier state.

That changed how I thought about the problem.

A deprecation page isn't just documentation.

It's changing data.

If you only store the current page, you can lose the fact that a vendor previously announced something.

The only way to catch it is to keep the earlier observations, not just the current page.

2. The same model gives you 3× the warning on one platform

How long do you get between "this model is going away" and "this model stops answering"?

Two vendors publish the answer as policy. Anthropic:

Anthropic notifies customers with active deployments for models with upcoming retirements, providing at least 60 days' notice before model retirement for publicly released models.

AWS Bedrock:

A model will be in the Legacy state for at least 6 months before the EOL date.

Both of them also publish the dates you need to check it. Anthropic dates each retirement announcement in its deprecation history ("On June 5, 2026, Anthropic notified developers…") and gives the retirement date in the table under it. AWS puts a Legacy date next to the EOL date.

So the notice period here is one subtraction, and both ends of it come from the vendor: start = the date the vendor says it announced the retirement (Anthropic) or moved the model to Legacy (AWS); end = the retirement or EOL date it published. No estimate, no first-seen date of my own.

	Retirements with both dates	Observed notice
Anthropic	19	60–189 days, median 63
AWS Bedrock	17 (every row)	181–185 days, median 184

Anthropic's spread is worth a second look: seven of the 19 ran 63 days, five ran 60–62, and the long tail (181, 181, 181, 189) is all from 2025. The five most recent are 60, 61, 62, 62 and 62 — the stated floor, near enough exactly.

AWS lands on six months in every single row, across five different model providers — AI21, Amazon, Anthropic, Cohere and TwelveLabs. That's a platform-wide rule, not a coincidence.

Now look at the models that appear on both:

Model	Notice from Anthropic	Notice from AWS Bedrock	Ratio
Claude Opus 4.1	61 days	184 days	3.0×
Claude Sonnet 4	62 days	183 days	3.0×
Claude 3 Haiku	60 days	184 days	3.1×
Claude 3.7 Sonnet	114 days	181 days	1.6×

Same model, same retirement, three times the runway — depending on which endpoint your code calls.

Two things before concluding that Bedrock is simply more generous.

AWS also guarantees a model stays available at least 12 months from launch, which Anthropic doesn't publish at all. But the back half of that six-month window isn't free:

During this public extended access period, active users of a Legacy model can continue to use it until the EOL date (for a minimum of 3 months), but you should expect higher pricing, which will be set by the model provider.

So part of the longer grace period is a paid extension.

And the other two vendors can't be measured. OpenAI and Google publish a shutdown date and no announcement date, so there's no start of the clock to subtract from. Google's table does carry a Release date, but that's when the model launched, not when it was marked for retirement. Whatever notice they give, their own pages don't say.

3. There is no standard "replacement model" field

Once a model is deprecated, the next question is what to migrate to. There is no common answer format.

AWS Bedrock's lifecycle table has no replacement column at all:

Model provider | Model name | Model ID | Regions | Legacy date | EOL date | Public extended access start date

It tells developers to move to the latest model before EOL, without naming a successor there.

Other vendors do provide replacement information:

Vendor	Rows checked	Rows with replacement
OpenAI	140	134 (the other 6 print "—")
Google	42 with shutdown dates	42
Anthropic	19	19
AWS	17 with EOL dates	No replacement field

This isn't necessarily a criticism of AWS. AWS hosts models from other providers, so recommending a particular successor can be a different product decision.

But the three that do publish it don't agree on where it goes.

OpenAI puts it in the deprecation table itself.

Google puts it in the deprecation table too — but only fills it in for rows that have a shutdown date. Rows marked No shutdown date announced mostly leave it empty, so "deprecated" and "scheduled" are separate states and only the second one tells you anything.

Anthropic doesn't put it in the model status table at all; that table has no such column. It's in separate tables further down the same page, one per announcement.

AWS has no field for it.

And OpenAI isn't consistent with itself: the same page uses Recommended replacement and Substitute model for the same concept. A human reads straight past that; a parser has to be told. Mine matched replacement, successor, recommended and alternative — but not substitute — so it silently lost replacement information for 26 models. The rows still had shutdown dates, so nothing looked broken; my site just showed retirements with no migration target.

That was my bug, not OpenAI's.

Four vendors, four structures, and one of them uses two inside a single document.

Update — August 15: a security fix did the same thing

On August 15, two days after this article went up, I watched the same pattern somewhere else entirely.

Claude Code v2.1.232 (August 13) listed this among its fixes:

Fixed a Windows permission bypass where Git Bash followed Cygwin-style symlinks that path validation saw as regular files; writes through them now require permission

v2.1.233, published about 23 hours later, says:

Reverted the 2.1.232 Bash permission changes for Cygwin-style symlinks on Windows and for input redirections (< file); a narrower version will return in a later release

The same release also fixes what it calls "a 2.1.232 regression" — auto mode repeatedly stopping for manual approval on ordinary cd <dir> && <command> > file commands. Which is presumably why the change was pulled: the tightening caught legitimate commands too.

Nothing here is hidden. Both lines are in the public release notes, and the revert is stated plainly.

But if you read the 2.1.232 notes on the 13th and upgraded for that specific hardening, the thing you upgraded for stopped being true on the 14th — and the only place that says so is the next release's notes, which you have no particular reason to read if you already upgraded.

Same shape as the Google case above: a published fact replaced by a later page. The differences are that the window was a day rather than a week, the vendor said so explicitly rather than silently, and it was a security fix rather than a date.

I've amended our own entry for 2.1.232 to record the revert, which is the part I'd have got wrong if I'd only read it once.

What surprised me

Before building this, I thought the difficult part would be collecting the data.

It isn't. Collecting it is a crawler and a parser.

A shutdown date can be announced and later disappear from the current page.

A model can have a different amount of notice depending on the platform.

A replacement model might be published—or not.

It might be in a different table, under a different field name, or only appear after another lifecycle state changes.

And the documentation itself changes while you're trying to monitor it.

The result is that answering a seemingly simple question—

"When does this model stop working, and what should I use instead?"

—can require multiple pages, vendor-specific parsing, and historical state.

The hard part wasn't collecting the data. It was making the data comparable.

Notes on the numbers

The numbers in this article are a snapshot taken on August 11, 2026.

Since then the AWS table has already shrunk. It listed 17 rows on August 11 and lists 13 today, because a row is removed once its EOL date passes — including the claude-3-7-sonnet row this article compares, so that one line can no longer be checked against the live page. Cohere's Command R and R+ reach EOL today, which will take it to 11. That is the article's point arriving on schedule.

The cross-vendor comparisons describe what was publicly documented at that point, not a complete historical record.

For the Google example, I have been continuously monitoring the relevant page since July 28.

I also deliberately left out figures where I couldn't distinguish between:

the vendor not publishing the information, and
my collector failing to extract it.

I've already had cases where the second explanation turned out to be true.

That was a useful lesson too.

AI Change Watch: https://aichangewatch.com/deprecations?src=devto

Next.js ISR Wasn't Revalidating on Cloudflare Workers — and `x-nextjs-cache: HIT` Lied to Me

ushiro — Tue, 11 Aug 2026 12:00:00 +0000

I spent months looking at x-nextjs-cache: HIT and thinking ISR was working. It wasn't.

I run AI Change Watch, a Next.js App Router site on Cloudflare Workers via OpenNext. It crawls AI vendor docs and pricing pages and publishes what changed. Every page carries export const revalidate = 300.

Background revalidation had never run. Not "ran slowly" — never ran, not once. And the header I checked to convince myself it was fine is structurally incapable of telling me otherwise.

Here is what was actually broken, why the header can't prove what I thought it proved, and the piece that's easiest to forget.

The symptom that isn't a symptom

revalidate = 300 was decorative. Pages did refresh, so nothing looked wrong.

They refreshed because a deploy changes the buildId, and the buildId is part of the R2 key space — so every deploy invalidated the whole cache. This repo deploys several times a day. The bug was covered by deployment frequency.

The logs told the real story:

BEFORE
  107  Failed to revalidate stale page      (3-day window, earliest 2026-08-03)
    0  successful background revalidations

AFTER
  196  events
    0  errors
   33  revalidate runs

33 re-renders that no user request triggered. That is what "working" looks like.

Three pieces have to line up

For Durable Object-backed ISR revalidation in this setup, three separate things need to be configured, and they are three different kinds of thing:

Queue configuration — queue: doQueue in open-next.config.ts
A Durable Object binding — NEXT_CACHE_DO_QUEUE + its migration, in wrangler.jsonc
A Worker service binding — WORKER_SELF_REFERENCE, also in wrangler.jsonc

I had none of them. The binding name and the class name are fixed by the adapter — they are not yours to choose.

The one that's easiest to forget

WORKER_SELF_REFERENCE fails in the most misleading way of the three.

The Durable Object does not render anything itself. It calls back into your Worker to do the render. Without the service binding, the job reaches the queue, but the revalidation worker cannot call back into the Worker:

No service binding for cache revalidation worker
53 occurrences in 8 minutes

The chain is:

  request ──> Worker ──> stale entry found
                 │
                 └─> enqueue ──> DO (NEXT_CACHE_DO_QUEUE)
                                   │
                                   └─> WORKER_SELF_REFERENCE ──> Worker renders
                                                                      │
                                            R2 <── writes fresh entry ─┘

Cut the self-reference and it dies at step 3 — but steps 1 and 2 still report success, so nothing surfaces as an error at the request path. Pages stay 200, because a MISS still renders through NextServer. The symptom is silent staleness, not an outage.

Why the header proves nothing

This is the part that cost me the most time.

x-nextjs-cache: MISS still renders through NextServer and still writes a cache entry. So:

You hammer a page. First response: MISS.
It renders and writes.
Every subsequent response: HIT.

You now have a page reading HIT whether or not the revalidation queue exists. Sampling cache state cannot distinguish "the background queue re-rendered this" from "somebody's request repopulated it." Both produce HIT. Both produce fresh-looking content.

I checked HIT across the site and concluded ISR was healthy. It was not, and the header was never going to tell me.

Judge on the logs instead. Filter Workers Logs on $metadata.level = error for failures, and count the revalidate info lines for actual DO-driven re-renders. That's where the 33 above comes from.

`enableCacheInterception` made it worse

If you don't set queue at all, OpenNext falls back to a dummy queue whose send() throws. Normally that throw is caught inside NextServer, so you get a log line and a stale page.

Then I enabled enableCacheInterception: true for the CPU savings. That serves ISR hits from the routing layer, skipping NextServer — which also moves the same throw outside NextServer's catch, and before the render:

Error in routingHandler
  at Object.send (worker.js:116290)
  at computeCacheControl (worker.js:120329)
  at generateResult (worker.js:120394)
  at cacheInterceptor (worker.js:121493)

Two properties made this much worse than a normal bug. It threw before the render, so the entry could never refresh and the 500 was permanent per URL. And it fired only once an entry passed revalidate, so pages went down one at a time over roughly 9 hours — 12 URLs before I reverted it.

The flag is not the villain; the order is. The CPU win is real. Confirm revalidation works first, then turn it on.

The wrong hypothesis: `/en/` → 307

Worth recording because it was well-argued and still wrong.

After the fix, Failed to revalidate stale page /en/... still appeared occasionally. Every failing path was under /en/, and middleware.ts issues a 307 from /en/* to the unprefixed canonical. Obvious conclusion: the redirect breaks the revalidation fetch.

Controlled test — hammer 6 /en/ pages and the 6 equivalent /ja/ pages past their revalidate window, 8 minutes:

83 successful revalidations
 0 failures
 both locales

If the 307 broke revalidation, /en/ would have failed dozens of times. It failed zero. The hypothesis died, and the middleware redirect — which is correct canonicalisation — stayed. Deleting it on a plausible-sounding theory would have bought a duplicate-URL problem for nothing.

What the data actually showed

The residual failures correlate with deploy churn. All four in that window landed 2.0–4.2 minutes after a deploy, during a stretch with four deploys in 22 minutes. They self-heal on the next request (MISS → render → write), never return 5xx, and did not occur at all in a steady period.

The mechanism I believe is behind that: a deploy changes the buildId and with it the R2 key space, so a revalidation enqueued across the switch has nowhere to land. See the caveat at the end — I have not proven this one.

The configuration that actually works

Both files, complete, as they run in production today.

// web/open-next.config.ts
import { defineCloudflareConfig } from '@opennextjs/cloudflare';
import r2IncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache';
import { withRegionalCache } from '@opennextjs/cloudflare/overrides/incremental-cache/regional-cache';
import doQueue from '@opennextjs/cloudflare/overrides/queue/do-queue';

export default defineCloudflareConfig({
  incrementalCache: withRegionalCache(r2IncrementalCache, { mode: 'long-lived' }),
  queue: doQueue,
});

// web/wrangler.jsonc  (only the parts relevant to ISR)
{
  "name": "changewatch-web",
  "main": ".open-next/worker.js",
  "compatibility_date": "2025-03-25",
  "compatibility_flags": ["nodejs_compat"],
  "observability": { "enabled": true },

  // The incremental cache store itself.
  "r2_buckets": [
    { "binding": "NEXT_INC_CACHE_R2_BUCKET", "bucket_name": "awc-web-cache" }
  ],

  // 2. The queue. Name and class are fixed by the adapter.
  "durable_objects": {
    "bindings": [
      { "name": "NEXT_CACHE_DO_QUEUE", "class_name": "DOQueueHandler" }
    ]
  },
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["DOQueueHandler"] }
  ],

  // 3. The self-reference. `service` must equal `name` at the top of this file.
  "services": [
    { "binding": "WORKER_SELF_REFERENCE", "service": "changewatch-web" }
  ]
}

Two notes on this config. new_sqlite_classes is what the adapter's handler expects and is the only option for new Durable Object classes. And mode: 'long-lived' on the regional cache is a separate lever from revalidation — short-lived pins every regional entry at 60s, which on this site was worth 300–380ms of response time. Different problem, same file.

Cost

Three separate meters, none of them your Workers CPU budget:

Meter	Included	Then
Durable Object requests	1M/mo	$0.15/M
Durable Object duration	400k GB-s (hibernating objects not billed)	—
R2 Class A operations	1M/mo	$4.50/M

Prices are Cloudflare's published rates as of August 2026 — check Durable Objects pricing and R2 pricing for current values.

Worst case here is roughly $0–1/month against ~$5.5–6.5 of Worker CPU. R2 storage does not grow, because revalidation overwrites the same key. If DO requests ever approach the included 1M/mo, raise revalidate — it scales all three meters together.

Checklist

For this setup, all three pieces need to be configured correctly for background revalidation to work end-to-end: queue: doQueue, the Durable Object binding with its migration, and WORKER_SELF_REFERENCE.
Never conclude anything from x-nextjs-cache. A MISS repopulates, so everything reads HIT eventually.
Verify by counting revalidate runs in the logs, not by sampling headers.
Failed to revalidate shortly after a deploy may be deploy churn. Don't treat it as an ISR outage unless it persists during a stable deployment period.
Add enableCacheInterception only after revalidation is confirmed working.

What I still haven't proven

Two things, so nobody takes them from this post as established:

The deploy-churn explanation is a working hypothesis, not a result. The failures correlated strongly with rapid deploys — all four within 2.0–4.2 minutes of one — and the buildId key-space rotation fits that timing. But I have not instrumented the R2 key at enqueue time to show that the key being written is the pre-deploy one. If you see the same pattern during a stable period with no deploys, my explanation doesn't cover your case and it's worth digging.

One failure mode is still open here: Failed to set to cache Error: put: Reduce your concurrent requests — R2 rate-limiting ISR writes during crawler sweeps, 17 occurrences over three days. Unresolved at the time of writing.

Docs worth reading properly rather than skimming: OpenNext Cloudflare caching, Cloudflare service bindings, Durable Objects, Next.js ISR, and Workers Logs for the verification step.

The site this came from tracks AI model and pricing changes across vendors: aichangewatch.com/changes/model. Every page on it is served by the setup above — which is how I found out it was broken.

IndexNow Returns 429 from Cloudflare Workers: What Actually Fixed It

ushiro — Mon, 10 Aug 2026 12:00:00 +0000

I build and run AI Change Watch: it crawls 15 AI vendors — OpenAI, Anthropic, Google, AWS Bedrock, Azure and the rest — and records every model deprecation, API change and price move as a dated, searchable event. That works out to a couple of thousand pages, each changing on its own schedule rather than on mine.

Building it also generates a steady supply of problems that took me longer to work out than they should have, so I'm going to start writing them up here: Cloudflare Workers, crawling at scale, edge caching, and the indexing plumbing that ties them together. This is the first one.

That volatility is what makes IndexNow a pretty natural fit. You POST a list of URLs, and Bing, Yandex, Naver and Seznam learn that those pages changed — no crawl budget negotiation, no waiting. It costs nothing and takes about twenty lines of code.

I run it from a Cloudflare Worker. For weeks, the worker reported success.

Bing had never received a single URL.

The submitter that couldn't tell you it was broken

The first problem wasn't network-level at all. It was this:

export async function submitIndexNow(urls: string[]): Promise<boolean> {
  const list = [...new Set(urls)].slice(0, 10000);
  if (list.length === 0) return false;   // <-- nothing to send
  // ...
  for (const endpoint of ENDPOINTS) {
    const res = await fetch(endpoint, { method: 'POST', body });
    if (res.ok) return true;
  }
  return false;                          // <-- everything rejected us
}

Both of those false returns surfaced to the caller as submitted: 0. "There was nothing new to send" and "every endpoint refused the batch" were the same observable event. A quiet day and a completely broken submitter looked identical in the logs, which is why this went unnoticed for weeks.

So before diagnosing anything, I made the two states say different things:

console.warn(JSON.stringify({
  at: 'indexnow', outcome: 'rejected', endpoint,
  status: res.status, urls: list.length,
  body: (await res.text()).slice(0, 200),
}));

The very next run printed this:

{"at":"indexnow","outcome":"rejected","endpoint":"https://www.bing.com/indexnow",
 "status":429,"urls":150,
 "body":"{\"errorCode\":\"TooManyRequests\",\"message\":\"We're sorry, but you have sent too many requests to us recently.\"}"}

Bing was returning 429 TooManyRequests. Every time. And because my endpoint list falls through on failure, the batch was quietly landing on Yandex instead — the one search engine I wasn't submitting for.

If you take one thing from this post: never let "nothing to do" and "the request failed" produce the same log line.

Proving it's the sender, not the payload

A 429 usually means "slow down", so the obvious suspects are batch size, frequency, or a bad host/key pair.

To rule those out, I kept the payload, the key, the keyLocation and the timing constant, and changed only where the request originated. All three of these went out within the same minute:

Sender	bing.com	api.indexnow.org	yandex.com
Cloudflare Worker	429	429	200
Residential IP (my laptop)	200	200	200
GitHub Actions runner	200	200	200

Same key. Same body. Same minute. The only variable was the sender.

Volume isn't the trigger either. Going back through older logs, a 4-URL batch got the same 429 three days earlier. A 150-URL batch gets it today. There is no batch size small enough to slip under it.

What this proves, and what it doesn't

Worth separating, because the two are not the same strength of claim.

What the experiment establishes:

The same submission succeeds or fails depending purely on where it is sent from.
The rejection is not a function of batch size, and not a problem with the key or keyLocation — those were identical in all three runs.
Therefore no amount of backoff, jitter, or chunking on my side would have fixed it.

What I'm inferring: that this is about shared egress IP reputation or per-IP rate limiting. Cloudflare Workers egress from address ranges shared with a very large number of other tenants, many of whom also submit to IndexNow, so a per-client limit would be consumed collectively.

That's a working hypothesis, not a demonstrated fact. Bing doesn't publish how its IndexNow endpoint rate-limits, and I have no way to observe it from outside. The official Bing IndexNow docs don't cover this case.

Fortunately the fix doesn't depend on the hypothesis being right. Whatever the mechanism, the actionable finding is the same: the request has to leave from somewhere else.

The fix: move the POST, keep the policy

The obvious move is "submit from somewhere else". The trap is rewriting the whole submitter in that somewhere else.

My Worker doesn't just POST a list. It decides what to send: it reads the site's own sitemap, ranks URLs by whether they've never been submitted, whether their lastmod moved, and how long since the last submission, caps the run, and records what landed in KV. That logic is derived from the site's indexing policy. Duplicating it in a CI script means two copies that drift the first time either side changes.

So I split the use case in two, and left both halves in the Worker:

// Reads the sitemap, picks the batch. Records NOTHING.
async plan(): Promise<SitemapPlan> { /* ... */ }

// Records a batch as sent. Called only after it was accepted.
async commit(batch: SitemapUrl[]): Promise<number> { /* ... */ }

Exposed as two endpoints, the GitHub Actions job becomes a courier that never interprets what it carries:

const plan = await admin('/admin/indexnow/pending?scope=sitemap');
if (plan.outcome === 'sitemap-unavailable') fail('the sitemap could not be read');
if (plan.batch.length === 0) { log({ outcome: 'nothing-due' }); process.exit(0); }

const urlList = plan.batch.map((u) => u.loc);
// ... POST urlList to the IndexNow endpoints ...
if (!accepted) fail(`every endpoint rejected ${urlList.length} URLs`);

// Hand the batch straight back, verbatim.
await admin('/admin/indexnow/commit', {
  method: 'POST', body: JSON.stringify({ batch: plan.batch }),
});

Two details that matter more than they look:

plan() records nothing. If the submission fails, the same URLs come back in the next plan. An earlier version marked URLs as sent before the POST, which meant one rejected batch silently retired 150 URLs for the whole refresh window — while reporting success.

commit() re-reads its state and drops foreign hosts. The batch makes a round trip through an external job, so on the way back it is untrusted input, not a trusted snapshot.

How it fits together

   Cloudflare Worker  ──plan()──▶  batch of URLs
   (sitemap, ranking,                    │
    KV state)                            ▼
          ▲                       GitHub Actions
          │                              │
          │                              │ POST
          │                              ▼
          │                          IndexNow
          │                        (Bing first)
          │                              │
          └────commit(batch)─────────────┘
                                    on success only

The workflow itself is unremarkable, which is the point:

on:
  schedule:
    - cron: '17 */3 * * *'   # odd minute: GitHub queues heavily at :00
  workflow_dispatch:

concurrency:
  group: indexnow            # two runs would fetch the SAME batch
  cancel-in-progress: false

That concurrency block is load-bearing. Since nothing is recorded until a submission is accepted, two overlapping runs would each ask for a plan, receive the identical batch, and submit it twice.

First real run:

{"at":"indexnow","via":"actions","outcome":"submitted",
 "endpoint":"https://www.bing.com/indexnow",
 "submitted":150,"recorded":150,"listed":1906,"due":1006}

endpoint is the first one in the chain. Bing took it directly.

A side observation: Yandex is fast, Bing is patient

While all of this was still landing on Yandex, I pulled six hours of crawler traffic (1,000-event sample):

Crawler	Hits
YandexBot	185
PetalBot	37
Applebot	13
bingbot	3
Googlebot	1

YandexBot went from background noise to dominant right after those submissions. IndexNow demonstrably causes crawling — Yandex just acts on a ping far more eagerly than Bing does.

One clarification worth making, because I had it wrong myself at first: IndexNow shares the notification between participants, not the crawl. A URL you submit to Yandex is advertised to Bing as well, but Bing still has to send bingbot and build its own index. "Yandex crawled it" never becomes "Bing indexed it".

And if you're wondering whether any of this reaches Google: it doesn't. Google has been evaluating IndexNow since 2021 and still doesn't participate. Sitemaps and Search Console remain the only levers there.

What I changed

The final setup:

The Cloudflare Worker owns URL selection and submission state.
GitHub Actions owns the outbound POST.
A failed submission is never recorded as sent, so the batch is safe to retry.
"Nothing to submit" and "submission failed" are separate, named outcomes.

The important part wasn't moving the request to GitHub Actions. It was separating policy from transport — and noticing that only the transport had a problem.

Takeaways

A successful fetch() is not the same thing as a successful submission.
Log "nothing to do" and "request rejected" separately. Everything else here was invisible until that one change.
When debugging a 429, send the identical request from a different network before assuming it's your rate.
Keep selection and state out of the transport layer, so relocating the transport costs you one small script.
Don't mark work as done until the receiving service says it accepted it.

All the numbers above are from production logs on 2026-08-09. This is also part of why AI Change Watch is built around event-level change detection rather than periodic re-crawling: when you record what changed and when, questions like "was this ever actually submitted?" have an answer you can look up.

DEV Community: ushiro

A `middleware.ts` Rewrite Silently Disables ISR in Next.js 15.5

What the headers said

Why this hides so well

The cause

Two things that did not fix it

The fix

The exclusion regex has two traps

How to check it, in the order that actually works

What I still haven't proven

The iCalendar Spec Says 75 Octets, Not 75 Characters

The line that RFC 5545 actually specifies

Why counting characters isn't the only bug

The other one: your UID is not a display string

What I check now

`next dev` Renders but Nothing Works: Your CSP Is Missing `unsafe-eval`

The symptom

The one line that names it

Why this happens in dev and not in prod

Why the header reaches dev at all

Two fixes, and they are not equivalent

The general shape

Your Worker Returned 500 and the Log Says `outcome: "ok"`

The part that works

Trap 1: a rendered 500 is a successful invocation

Trap 2: a wide time window silently undercounts

Trap 3: exists matches empty strings, and includes ignores case

Trap 4: event counts are not invocation counts

What I actually run now

The one-line version

A Missing ID Doesn't 404 — It Fetches the Whole Collection

What that did to my site

Why it survived so long

The actual shape of the problem

The fix, and where it goes

How to find this in your own code

Google removed an announced Gemini 2.5 shutdown date with no changelog entry

1. A previously announced shutdown date can disappear

Was the change announced anywhere?

2. The same model gives you 3× the warning on one platform

3. There is no standard "replacement model" field

Update — August 15: a security fix did the same thing

What surprised me

Notes on the numbers

Next.js ISR Wasn't Revalidating on Cloudflare Workers — and `x-nextjs-cache: HIT` Lied to Me

The symptom that isn't a symptom

Three pieces have to line up

The one that's easiest to forget

Why the header proves nothing

enableCacheInterception made it worse

The wrong hypothesis: /en/ → 307

What the data actually showed

The configuration that actually works

Cost

Checklist

What I still haven't proven

IndexNow Returns 429 from Cloudflare Workers: What Actually Fixed It

The submitter that couldn't tell you it was broken

Proving it's the sender, not the payload

What this proves, and what it doesn't

The fix: move the POST, keep the policy

How it fits together

A side observation: Yandex is fast, Bing is patient

What I changed

Takeaways

Trap 3: `exists` matches empty strings, and `includes` ignores case

`enableCacheInterception` made it worse

The wrong hypothesis: `/en/` → 307