i was under the impression CF ran its own pops/colos, the fact KV is 100% reliant on GCP is concerni
i was under the impression CF ran its own pops/colos, the fact KV is 100% reliant on GCP is concerning
JKV started responding successfully to me
Tay seems to be working now
1I think the issue is that a lot of backend config stuff is stored in KV in US Central, which also happened to be the location hardest hit by the looks of it
Pdidn't last big outage show holes in their config architecture? thought that was all being mitigated 
SError listing KV entries: KV GET failed: 503 Service temporarily unavailable Hopefully it hits me soon 
Sayyy there it is
Cimportant backend stuff/anything config should be QS (Quicksilver, Cf's own replicated edge kv db)
Cthat's why websites/cdn/proxy continued to work fine
CKV is (clearly now) GCP dependent, and CF Access, dashboard, etc, depend onKV
Dall my kv are still down, i guess they only recover KV by geographic location or something?
Chere's def still some errors, thundering herd problem and all that, recovery is slow
CAll Cloudflare services have been restored and are now fully operational. We are moving the incident to Monitoring while we watch platform metrics to confirm sustained stability.
Rall my sites use KV, and they're all back but 1. For some reason that 1 is still throwing the KV 503.
Rthrows it on both the site and the in the worker ide.
Dfor me it's starting to come back. One thing to say about Cloudflare is that they "eat their own cooking", so if something like KV goes down, even they are screwed, and they've got a lot to lose. So in that sense, issues with something like KV are attended to almost immediately. That being said, this was a pretty bad outage and for me at least, I am reluctant to rely on it as much as I have
RThe same is true for pretty much everyone. When kenisis went down in AWS a couple years ago, it took out most of AWS's provisioning and updating tools
DJust started getting KV failures again. This thing is not stable.
1Seems to be working fine for me 
AIt was a major outage. CF GCP and AWS were affected.
https://www.livemint.com/news/us-news/netizens-claim-major-internet-outage-caused-by-cyberattack-all-details-on-cloudflare-gcp-downtime-here-11749765997009.html#
https://www.livemint.com/news/us-news/netizens-claim-major-internet-outage-caused-by-cyberattack-all-details-on-cloudflare-gcp-downtime-here-11749765997009.html#
Cnah, aws was fine. It was just GCP failing which cascaded into CF/Spotify/etc (and CF's customers, etc)
CAuthor is drunk. They wrote wednesday many times
A:bibicat:
THi folks, we published an update on the service outage yesterday here: https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/
Clol def not Google Sheets. They were using one of Google Cloud's products. They weren't specific on which ones they are dependent on, but you could make an educated guess
CWhy are all the explanations being so vague?Transparency is nice and it'd be cool to see a blog post about what exactly is used under the hood, but I mean for an incident report the bottom line is just: Cloudflare's products failed for hours due to an outage. Themselves, upstream or not, it's their responsibility to make systems reliable and not have downtime, and they detailed they're working towards that
imo you can't (and they didn't, they didn't even name GCP) just blame partners for outages, when you're the one responsible for picking them and ultimately providing the service.
CI would note that they said at one point they had another fail-over/partner
Workers KV removed a storage provider as we worked to re-architect KV’s backend
Moving the object store inhouse does not solve the issue of lack of fall-over. What if a problem with R2 causes a similar issue in the future?I don't think they were really clear fully on their plans, maybe they plan on their own + GCP as a backup. R2 is their service/internal to them, even if they planned on going with just R2 if there's any issues it's internal to them/for them to fix. Basically them being in control of more the infra in the same way GCS does for example
CMaybe an employee can comment on that a bit more or in a future blog post about hardening KV. They could have internal failovers for R2 too by using its multiple regions and such
!Hey, quick question, the credentials for the KV when we move things to prod? Am I suppose to add it to the env vars, but how can I retrieve those
DI'm wondering why the dashboard for KV in cloudflare admin dashboard doesn't allow you to see the metadata for KV or edit this metadata? You can see the key and value, and edit those, but not the metadata. Is there anything in the works to fix this dashboard and expose the metadata because this makes the dashboard kind of useless for many KV applications, Thanks.
AI'm running into the same issue. Did you figure out a fix @@zecanard ?
AHey folks,
We accidentally set the
We went back and updated the
Any idea how to fix this?
We accidentally set the
cacheTtl for a KV.get() to 300000s (~3.5 days) instead of 300s (5min). That resulted in caching the values and seeing stale data for longer than expected.We went back and updated the
cacheTtl to be 300 after a couple days when we realized there's an issue with stale data, but we are still seeing stale data regardless. The fix was merged more than 2h ago, and fetched some entries to reset the cacheTtl as the docs say here, but no luck.Any idea how to fix this?
The effective cacheTtl of an already cached item can be reduced by getting it again with a lower cacheTtl. For example, if you did NAMESPACE.get(key, {cacheTtl: 86400}) but later realized that caching for 24 hours was too long, you could NAMESPACE.get(key, {cacheTtl: 300}) or even NAMESPACE.get(key) and it would check for newer data to respect the provided cacheTtl, which defaults to 60 seconds.
Cloudflare Docs
To get the value for a given key, call the get() method of the KV binding on any KV namespace you have bound to your Worker code:
ZI think it was Micky who created a ticket to look into this for me. The problem seemed to resolve itself after two weeks, then everything was working fine for a while. However, recently I made another update to my KV, and the problem reoccurred for a few days. So it doesn't seem to be fixed at all.
AWow! 2 weeks!! OMG 
.
Did you set the cacheTtl to 2 weeks that's why the cache lasted that long, or 2 weeks is just a random thing?
.Did you set the cacheTtl to 2 weeks that's why the cache lasted that long, or 2 weeks is just a random thing?
ZIt was just random. I use a TTL of one year, and expire my KV cache whenever I update the values.
OSo I get an error trying to use
✘ [ERROR] In development, you should use a separate kv namespace than the one you'd use in production. Please create a new kv namespace with "wrangler kv namespace create <name> --preview" and add its id as preview_id to the kv_namespace "CROM" in your wrangler.json file
And I follow the instructions and update my wrangler.jsonc:
And I still get the same error? Am I missing something?
--remote:✘ [ERROR] In development, you should use a separate kv namespace than the one you'd use in production. Please create a new kv namespace with "wrangler kv namespace create <name> --preview" and add its id as preview_id to the kv_namespace "CROM" in your wrangler.json file
And I follow the instructions and update my wrangler.jsonc:
"kv_namespaces": [
{
"binding": "CROM",
"id": "cda6c32602a643b1ac92d1f8bac5abff",
"preview_id": "721f44f1924843a68312f39dc99192a1"
}
]And I still get the same error? Am I missing something?
OI am trying to run the code with
npx wrangler dev --remoteOCROM and CROM_preview both exist in my dashboard as expected.
OGot it. Need to build first. I guess --remote requires the built project.
Mhello
Ki was trying to build a POC where i wanted to add items as a tree. keys would be /master/child1, /master/child2 and then i would call list with /master/ prefix to get the child item keys and since the doc says list will always return keys in alphabetical order, i was hoping when delete child1, the next list1 call would return /master/child2 as the first item. however, for about a minute the list calls keep returning /master/child1. is this the expected behavior? i was making the list calls from within a workflow if that might be a factor somehow. replaced kv calls with a simple insert, select for d1 in the very same setup and the problem went away which made me think there must be some sort of caching for kv then.
Rhey guys
I was wondering if there's a way, possibly through a support ticket, to get a dump of a KV namespace
I have tried exporting the data via a script, but since the API only allows reading 100 records at a time, and I have 1.96M keys, it's gonna take ages
Is there a better way?
I was wondering if there's a way, possibly through a support ticket, to get a dump of a KV namespace
I have tried exporting the data via a script, but since the API only allows reading 100 records at a time, and I have 1.96M keys, it's gonna take ages
Is there a better way?
DDoes KV have any native backup systems by chance or is it expected to do this on your own?
Vim working on a monorepo with multiple workers, how do i get kv to work across workers with the same namespace in development?
ie, if I post something to kv in worker 1, can i get it in worker 2?
ie, if I post something to kv in worker 1, can i get it in worker 2?
