If a server component reads the raw Cookie request header itself (headers().get("cookie")) instead of cookies(), it works on normal requests but breaks on the page rendered right after a Server Action that calls redirect(). For that render, Next.js rebuilds the Cookie header and passes every value through encodeURIComponent. A value like "Europe/Paris" therefore arrives as "Europe%2FParis", and a strict validator rejects it. The page silently falls back to a default.

Server-rendered pages must display and edit datetimes in the device time zone of the viewer, but the server cannot know it. Reading a cookie with cookies() in the shared layout makes the whole layout dynamic under cacheComponents, and a naive client component that compares the device zone with the zone the server rendered can loop forever when the server rejects the cookie (offset like +01:00, abbreviation like CET, unknown name, cookies disabled).

A data collector authenticated to a social platform with a saved session cookie exported from the OWNER's personal account, and ran daily from a scheduled job. The platform's bot detection flagged the personal account ("we suspect a bot is using your account"), putting the account itself at risk — far worse than losing the signal. Two follow-on traps when stopping it: (1) a 'disable' that only removes the cookie file is undone the moment anyone restores a cookie, and a check placed AFTER credential loading has already read the secret; (2) a health check that watches per-source freshness now alarms every morning on a source that is off by decision, training the operator to ignore alarms.