I also had problems when I tried CloudFlare. Different problems, but it cost me a few days contacting users and apologising before I U-turned and switched the nameservers back.
I unfortunately use PayPal and their Instant Notification thing, basically a callback to a web page with a POST about the transaction that just happened. Upon receiving the POST I can then do things like notify the customer, dispatch goods, award virtual goods, etc.
The problem I had was that after putting my website (in the London Linode datacenter) behind CloudFlare, PayPal started randomly failing to reach the callback page.
PayPal, being PayPal, failed silently for a few days before finally sending an email to say that they couldn't notify me of transactions. I figured it out just before that though, because users were getting the CloudFlare "site offline" message.
The pages on my site are 100% dynamic, so nothing was cached by the feature that keeps a site online.
My biggest problem with CloudFlare was visibility for debugging: I had no visibility.
If it wasn't for my users letting me know and PayPal emailing me confirming what I thought... I wouldn't have known. Even then it took too long to find out, over a week from when it started to fail silently.
According to Linode there was no downtime in that period, and according to my server logs load was never above average and there was no reason it should've been unable to be reached.
Did I submit a ticket? I submitted some questions beforehand and got back answers that were very friendly but not technically detailed. That's also how I found the interface, I couldn't debug using CloudFlare, no way to answer the questions "What is happening? Why is it happening?". So no, when I figured it out I wasn't going to stay with CloudFlare as even if it was resolved I would still lack visibility for future problem-solving.
In the end it was costing me goodwill with my users.
I wanted things you didn't provide:
How often did CloudFlare fail to contact my network?
Can I see a chart of such failures over time?
What were the failure error codes and times so that I can cross-reference them to my logs?
Basically: I wanted transparency so I could have confidence in the service, and detail so that I can debug failures when they occur.
And I was going to email this as it's really a "just to let you know". But you have no email in your HN profile, and looking through the support emails I had I see tenderapp.com and can't make a guess what your email address may be, and I pinged you on Twitter but no response and it's very late here... so posting it so you can see.
If you add ways for developers to debug issues when using CloudFlare then I may well be tempted back in the future. The fundamental premise is a good one and I really wanted it to work (paid for the Enterprise level, had every intention of using it). But when failing silently costs real money and customer goodwill, I don't feel I had a choice but to U-turn very rapidly.
As soon as I was off CloudFlare, PayPal Instant Payment Notification worked again and there hasn't been a single failure since.
I had similar experiences with CloudFlare. Wanted to use them, but they could give me absolutely 0 visibility into why they thought my site was down. I could load it in another tab using the raw address while CloudFlare kept serving the couldn't contact page.
Support was fairly unhelpful, basically just saying "sometimes this happens, and it usually clears up".
And this is precisely why I don't bother reporting Cloudflare's failures to site operators anymore. I used to do it, when it was pretty infrequent. Site operators were usually concerned that something was blocking customers, but most were clueless about what was causing it or how to fix it.
Eventually I gave up. I don't even bother with their captchas or other stupid human tricks anymore. Whenever Cloudflare gets between me and the site I'm trying to use, I move on and shop somewhere else. Life's too short for this.
This seems to throw lots of issues out, but no solutions. People aren't using cloudflare for no reason.
One small example, everyone is aware cloudflare is down sometimes, but if you ever get even lightly DDOSed, your uptime on cloudflare is likely to be much higher than without.
Cloudflare seems to have provided a service that fixes a lot of the issues you mentioned, so I'm not sure why you're mad at Cloudflare for making the best of this bad situation.
I've been a cloudflare user and advocate for many years. I even hold a small amount of NET stock. A few months ago I enabled their web3 offering which gives you an ethereum gateway and added it as a backup to an other gateway I had set up for a small site of mine which gets around 1000 unique visitors a day. It has been running in the free tier for awhile and I thought everything was fine.
Then I got an invoice for $400, I immediately removed cloudflare eth gateway from my site and thought I had unsubscribed from the web3 service on cloudflare's site. The next month I got another $490 invoice (~49 million requests) and saw that it was still enabled on the site so I completely deleted and removed it as best I could from their UI. Additionally their website dashboard UI has zero visibility into where the traffic comes from, how much there is or what the bill will be until you get an invoice.
This is the entirety of the information you get in the invoice (1):
> Ethereum Gateway Queries (First 500,000 requests are included
> 01/17/2023 - 02/16/2023 48,788,614 $0.00 $490.00
I sent a support email asking if they would consider a refund as the traffic was very likely not from my site visitors, one feature other ethereum gateway service providers offer that cloudflare does not is the ability to add a domain whitelist or even API key authentication. Cloudflare just lets you set up a domain name that they happily accept any requests to. I should have assumed someone would have abused it but unfortunately I did not. However without any data provided it would be entirely possible for cloudflare themselves to have a bug that mistakingly hits my set up domain and inflates the bill. At the least I would like to be able to see where the requests came from, on what dates, and other information.
The support ticket was open for 12 days unanswered, I sent a follow up reply and the next day the ticket was closed with this message:
> Cloudflare only issues refunds in very specific situations, such as fault in service. As this is not the case, we will not be able to attend your request.
I accept that I'm liable for the charges and have no recourse, but I wanted to share this as a warning to others and also to hopefully reach some cloudflare employees or leadership about the need for better visibility into paid features usage. Being able to set up access rules for the service and having user set limits would also be very helpful. With this service in particular there is zero way to prevent someone from abusing it as all the customer can do is point DNS to cloudflare's managed server.
I got the same issue today when I was on-call. took me 1 hour to figure out it was Cloudflare.
I'm currently working on a project to monitor all the 3rd party stack you use for your applications. Hit me up if you want, access I'll give free access for a year+ to some folks to get feedbacks.
I was doing a couple of POSTs a minute on a paid plan, and I saw a random 2-3% of request to be failing they never hit my backend, speaking to support wasn't helpful at all, that's when we moved away from Cloudflare, I wouldn't base my business on it.
That was the part that bugged me. This workflow is very busted from a user standpoint, though I'm sure it works very nicely to Cloudflare!
It smells like the "problem" was detected by automation, but instead of being able to reach anyone technical to work through it, you can only call sales teams.
I have no affiliation with CloudFlare at all, but my interactions with them have all been kind, professional, and courteous.
I might recommend reaching out to the CEO, Matthew Prince, with a succinct explanation of your problem and I would be surprised if that by itself does not kick off some serious positive action!
I saw a lot of slowdowns (expected, and not major) while I tested out Cloudflare, but the worst part about the experience was the dropped requests that somehow got stuck between the users browser and my servers.
I tried to debug it, and gave a script to their engineers to reproduce, but we did not find a solution.
I unfortunately use PayPal and their Instant Notification thing, basically a callback to a web page with a POST about the transaction that just happened. Upon receiving the POST I can then do things like notify the customer, dispatch goods, award virtual goods, etc.
The problem I had was that after putting my website (in the London Linode datacenter) behind CloudFlare, PayPal started randomly failing to reach the callback page.
PayPal, being PayPal, failed silently for a few days before finally sending an email to say that they couldn't notify me of transactions. I figured it out just before that though, because users were getting the CloudFlare "site offline" message.
The pages on my site are 100% dynamic, so nothing was cached by the feature that keeps a site online.
My biggest problem with CloudFlare was visibility for debugging: I had no visibility.
If it wasn't for my users letting me know and PayPal emailing me confirming what I thought... I wouldn't have known. Even then it took too long to find out, over a week from when it started to fail silently.
According to Linode there was no downtime in that period, and according to my server logs load was never above average and there was no reason it should've been unable to be reached.
Did I submit a ticket? I submitted some questions beforehand and got back answers that were very friendly but not technically detailed. That's also how I found the interface, I couldn't debug using CloudFlare, no way to answer the questions "What is happening? Why is it happening?". So no, when I figured it out I wasn't going to stay with CloudFlare as even if it was resolved I would still lack visibility for future problem-solving.
In the end it was costing me goodwill with my users.
I wanted things you didn't provide:
How often did CloudFlare fail to contact my network?
Can I see a chart of such failures over time?
What were the failure error codes and times so that I can cross-reference them to my logs?
Basically: I wanted transparency so I could have confidence in the service, and detail so that I can debug failures when they occur.
And I was going to email this as it's really a "just to let you know". But you have no email in your HN profile, and looking through the support emails I had I see tenderapp.com and can't make a guess what your email address may be, and I pinged you on Twitter but no response and it's very late here... so posting it so you can see.
If you add ways for developers to debug issues when using CloudFlare then I may well be tempted back in the future. The fundamental premise is a good one and I really wanted it to work (paid for the Enterprise level, had every intention of using it). But when failing silently costs real money and customer goodwill, I don't feel I had a choice but to U-turn very rapidly.
As soon as I was off CloudFlare, PayPal Instant Payment Notification worked again and there hasn't been a single failure since.
reply