Over the 90 days ending September 23, 2026, Cloudflare recorded 99.89% uptime with 2 major or critical incidents totaling 142 minutes of downtime, and Vercel recorded 99.91% uptime with 2 incidents totaling 120 minutes. On the raw numbers these two are close enough that picking one over the other for reliability reasons alone would be a mistake; what separates them is blast radius, meaning how much of your store stops working when each one fails.
These figures come from StatusBird's independent 2-minute monitoring over the 90 days ending September 23, 2026, not from vendor status pages.
What do the 90-day numbers actually say?
| Service | Uptime | Grade | Major/critical incidents | Total downtime | Average incident | Last incident |
|---|---|---|---|---|---|---|
| Cloudflare | 99.89% | B+ | 2 | 142 min | 71 min | 2026-08-12 |
| Vercel | 99.91% | A | 2 | 120 min | 60 min | 2026-07-23 |
Same incident count, 22 minutes of difference in total downtime, and 11 minutes of difference in average incident length. That gap is smaller than the time most store owners take to notice something is wrong, confirm it is not their own deploy, and post anything to customers. Treat the two as roughly equivalent on frequency and recovery speed.
For context inside the same category, AWS and Google Cloud both came through the window at 100% uptime with no major or critical incidents. Cloudflare and Vercel sit slightly below that, and both sit above Shopify, which logged 99.9% uptime and 124 minutes of downtime across 2 incidents in the same period. Live views are on the Cloudflare status page and the Vercel status page, with full history on their Cloudflare and Vercel reliability pages.
Why does a Cloudflare incident hit differently than a Vercel one?
Cloudflare usually sits in front of everything. If your DNS is hosted there and your records are proxied, then an incident affecting the proxy or the resolver can take down your storefront, your admin subdomains, your image CDN, your API endpoints, and any webhook receivers you run behind it at the same time. It does not matter that Shopify itself is healthy: requests never reach it.
Vercel sits in a narrower place. It hosts an application, typically a headless storefront front end, a marketing site, a landing page set, or a set of serverless functions. When Vercel has an incident, whatever runs there stops responding, but your Shopify checkout, your payment processor, and your fulfillment tooling keep running unless the front end is the only way customers reach them.
So the practical ranking flips depending on architecture. For a standard Shopify store that uses Cloudflare only for DNS and a proxied root domain, 142 minutes of Cloudflare trouble is potentially 142 minutes of no storefront. For a store whose Vercel project serves a blog and a few campaign pages, 120 minutes of Vercel trouble costs organic and paid traffic to those pages and nothing else.
Which one should your store worry about more?
Standard Shopify or BigCommerce store
Cloudflare matters more, and the exposure is entirely a function of how you configured DNS. If your A or CNAME records for the apex and www are proxied (the orange cloud in the Cloudflare DNS tab), every customer request passes through Cloudflare. If they are DNS-only (grey cloud), a proxy incident does not break your storefront because traffic goes straight to the platform. Vercel is likely irrelevant to you unless an agency built something there.
Headless storefront on Vercel
Both matter, and they stack. A headless build typically has the domain on Cloudflare pointing at Vercel, which then calls the Shopify Storefront API. Either layer failing takes the storefront offline, so your effective exposure over the window was the sum of the two: 4 incidents and 262 minutes across both vendors. That is the number to plan around, not either service's individual figure.
Store using Cloudflare Workers, Images, or R2
Cloudflare matters more again, and worse than DNS alone. Product images, redirect logic, geo routing, and bot rules living in Workers all fail together. A storefront that loads but shows no product images converts close to zero, and it will not trip a simple homepage check because the HTML still returns 200.
What should you actually do during each outage?
Cloudflare incidents, in order:
- Confirm it is Cloudflare and not your origin by loading your store on mobile data with a different DNS resolver. If the platform is up and the domain is not resolving or returning a Cloudflare error page, the layer is the problem.
- In the Cloudflare dashboard, open your domain, go to Overview, and check Advanced Actions for Pause Cloudflare on Site. Pausing sends traffic straight to your origin and bypasses the proxy, WAF, and cache. This is the single fastest lever if the incident is proxy-side and your origin is healthy.
- If you only need part of the site back, grey-cloud specific DNS records instead of pausing the whole zone.
- Expect cached asset behavior to change once you bypass. Watch page weight and origin load, especially if Cloudflare was serving your images.
Vercel incidents, in order:
- Rule out yourself first. Open the project's Deployments tab and check whether the most recent production deployment coincides with the failure. If it does, promote the previous good deployment back to production before blaming the vendor.
- If the platform is the cause, check whether the failure is builds only or serving too. A build-system incident means you cannot ship changes but live traffic is fine, which is an inconvenience rather than an outage.
- For a headless storefront, point customers at a path that does not depend on Vercel. If you keep a Shopify-hosted checkout domain or a backup landing page on the platform itself, publish that link in ad destinations and your email footer.
- Pause paid traffic to any Vercel-served landing pages while they are returning errors, then resume once you have confirmed a 200 response yourself rather than waiting for the status page to be updated.
How should you monitor two layers that fail independently?
Monitor the vendors and your own storefront URL separately, because they answer different questions. A vendor check tells you whose problem it is. A storefront check tells you whether customers can buy. In a Cloudflare plus Vercel stack, you want alerts on all three, and you want the storefront check to request a real product page rather than the homepage so that a cached shell does not mask a broken data layer.
One more habit worth building: record which of your domains and subdomains are proxied through Cloudflare and which of your pages are served by Vercel, and keep that list next to your outage runbook. During an incident, the slowest part is usually not the fix, it is working out which of your properties are affected. Monthly totals across the whole stack are on the outage index, and how uptime is calculated here is documented on the methodology page.
If you want to know when either layer starts failing before a customer emails you about it, StatusBird checks both Cloudflare and Vercel every 2 minutes alongside your own storefront and sends alerts by SMS, email, Slack, Teams, or Discord. You can set up monitoring here.