Recently we have been getting 8000000 errors when deploying pages from github actions with https://g
Recently we have been getting 8000000 errors when deploying pages from github actions with https://github.com/cloudflare/pages-action
TJudging by the forums I am not the only one:
https://community.cloudflare.com/t/code-8000000/554254/5
https://community.cloudflare.com/t/code-8000000/554254/5
AYup it's happening for me as will. pages-action started failing in CI
AIs this the correct place to raise the issue? We need some deployments to go out and this is a hard blocker it seems. I'm assuming it's broken for almost everyone?
I tried to run deployments manually via the wrangler cli and it didn't work.
I tried to run deployments manually via the wrangler cli and it didn't work.
ZAHmm I don't think it get's to the deploy step. Here is the output for me
ZAh, so this only seems to happen when deploying with Wrangler?
AThings to notice
- It took 95 seconds to upload assets, that is VERY unusual
- Even in CI, it gets to the same spot and fails. Tldr the whle process takes very long and then fails at the end
AI don't really use the pages github connection so I can't say for sure if that's working or not
AAll my deployments run through
pages-action on github (which is basically the wrangler cli)ZOkay, let me quickly see if I can reproduce it. What version of wrangler are you running?
A3.7.0AActually, interesting update, I followed the recommendation on one of the community posts, running
wrangler logout and then wrangler loginOdd 
AWhat's odd is, obviously in github actions it's just using an API key, but that's failing too.
MI'm using the GitHub integration and all my deployments started to fail too. But the CF status page shows no incident
ZI have escalated it to the team
AOk, I re-ran my other github actions just to double check some things.
It's not just pages deployments that are failing, it's workers too
It's not just pages deployments that are failing, it's workers too
TUnfortunatly I cannot see a deployemt Id
AFYI for everyone who can't get it working on github CI. Using a brand new API token fixes the issue (got the clue after wrangler login + logout fixed things)
EHi all, the issues with Pages seem to be related to this incident - https://www.cloudflarestatus.com/incidents/61k89lv1wns0
EI think it could also have been that you happened to retry after we managed to resolve the issue
ECould you let me know if you see this again?
ADefinitely possible
AJust some general feedback, the pages deployment error happens infrequently from time to time. Usually re-trying just fixes it. Obviously this time there was some critical underlying issue.
But in general, I think the stability of the pages deployment could use a bit of improvement
But in general, I think the stability of the pages deployment could use a bit of improvement
Hguys, sorry for maybe a dumb question, I understand that Cloudflare pages designed to serve as CDN, but is there any workaround to have directory listing there
if I there is no index.html show the folders like how local server does
if I there is no index.html show the folders like how local server does
Hin cloudflare it just returns not found
ZThere was this incident that included pages, but that should be resolved: https://discord.com/channels/595317990191398933/895794943182909470/1149613685237628958
ZAre you still seeing this happen now?
ZThis happens when trying to deploy using wrangler, correct? Could you try logging out of wrangler and back in, and then re-deploying?
EDo you have any deployment IDs visible or log output from wrangler to share?
ECan you share as much log output as you have and your
.pages.dev project domain?EThats the one, thank you very much
EBoth ideally! You can DM them to me if youd prefer they be kept private, or just send here
EAs much log data as possible
BHey! Last two days I’m seeing occasional increases in the TTFB for static projects on Pages. Anyone else experiencing this? Or is it common for lower traffic sites (there are daily users but an hour without is possible)
ULow traffic = low cache rate = longer response times
Uhigher traffic = higher cache rate = faster response times
EHI! We are getting notifications from https://www.repo-lookout.org/ that our **.pages.dev/.git/logs/HEAD is accessible. Where could I block access to that path?
KHave you verified that it is accessible and not just showing index.html w/ a 200?
BAlright thanks! It’s indeed always the less frequently visited sites
BNvm it doesn’t appear to be the less frequently visited sites only
BGetting 10s ttfb also on a static site with regular visitors
BAnd more frequent spikes, like once every 1 to 2 hours for every static site
