But if you wanted to do a file store and just pay for the usage, that's what KV and R2 are great for
But if you wanted to do a file store and just pay for the usage, that's what KV and R2 are great for 
W(note that this is ok to be done with our storage, putting them in R2 for example and serving is fine)
Jtoo slow walshy 
BIs this pertaining to me?
JNo, this was in reply to marais
Jwell, not really. The traffic is from other websites, so proportionally, that zone is serving way more file content than it is html content
Jr2 or kv are specifically file stores that you can use and pay for usage in storage, reqs, etc.
Jworkers are usage-based, so almost certainly not, no
Jrealistically, if you're concerned about your usage, I'd recommend you reach out to your account team and explain your use-case and get them to clarify/provide insight. These kind of situations are outliers
JI can only speculate - how much other traffic do you serve? what's your total bandwidth/req usage?
Jbandwidth?
Jyeah okay, I wouldn't worry
Juntil we're talking tens of TBs or more, this is almost certainly unlikely to ever be a problem
Jand at that point, you can probably consider an ENT contract and account team
JI'm not really sure I follow. At a point that you hit the scale that you're serving tens of TBs or more, you'll probably want to consider upgrading your plan, and then eventually reach ENT. Like you would with any usage-based service 
J(disclaimer that I'm not with Cloudflare, just a helpful community member)
JI agree this situation was unfortunate. The biggest issue here imo was the lack of reporting in the dash, and the alert just being an email - that sucks. Bad automated detections for this kinda thing are something that's affected cf for a while across various products, and I know it's something very much top of mind internally right now to improve
JI think it's a pretty common thing with any saas that as you grow, so will your bill. But cf can definitely do a LOT to improve reporting and reassurance around this. People should not be scared to grow with cf, and it really sucks that that's a growing sentiment 
JI think if the alert was more pro-active and not "sorry, it's yeeted", a much more open and productive convo could be had about costs, scaling, etc. But yep, it completely sucks that things just get yeeted and all you get is a "sorry, it happened" email, and no time to prepare
Jit's a massive area of improvement that cf need to invest a lot of time and devrel into, imo. You're totally right - people are scared, concerned, and worried about building and growing with cf right now.
Janecdotally, I know way more people that haven't ever had issues than those that have. I know that's a completely bs statement, but I don't have a whole lot else to reassure you right now unfortunately Realistically with your current usage, I wouldn't be worried for a long time, like 1000+ times your current usage
Realistically with your current usage, I wouldn't be worried for a long time, like 1000+ times your current usageJnothing officially documented, but again anecdotally I'd be thinking spikes of tens of TBs or more
Janecdotally again, I wouldn't think of it as a "ceiling" specifically, but more like congestion, for example if there was tens of TBs spiking in a single location, that's the kinda thing you might see throw red flags
Jit's all variable and complex, but yeah the tl;dr is that I agree people shouldn't be scared to grow with cf - that sucks that's it's a recurring sentiment