Analytics shows extra 404 worker request that I shouldn't pay for

I tried using logflare app, and also add trace code base on the code from:

to save the http logs on logdna.
both didn’t log any 404 request.

I am not sure where does 404 request came from, should I pay for those requests?

Add <link rel=icon […]> to your website, if you’re not using a favicon, and the numbers should drop precipitously.

That’s not a cure-all, of course. We should still identify how to view a log of 404s.

thanks for the tip, at first it was this reason. and while I run “wrangler dev” locally, it will shows that there is request of favicon. but after I added " <link rel="icon" href="data:,">" in the return content.
there is no favicon request at all.

but as the screenshot shows, the 404 request still exists… and also 503, though very few, but there was many earlier, like I posted here:

also seems no way to capture the http logs. even with logflare app, or logdna. the error status code seems never reach the worker.

I also use multiple Response.redirect(destUrl); method, not sure if this will generate 404 requests.

Where is your server running? You should be able to view access logs from that machine or service.

actually my worker’s function is like short url service. once receive request, it modifies the url and do 302 redirection. so the logs on target server may not useful because it’s a totally new request.

You could write out logs from the worker. Maybe it’s unexpectedly returning 404s under some conditions.

as for log, I have already send all logs to logdna base on this code:

but not found any 404 at logdna.

do you mean to add console.log()?

Hold on, is your worker’s trigger missing some requests?

I think not, currently I have two Routes:

> www.mydomain.org/*
> mydomain.org/*

and all the link came through:

> mydomain.org/*.

and handle all incoming requests in the fetch listener like this:

addEventListener('fetch', event => {
  event.respondWith(logRequests(event));
})

It couldn’t hurt to try *example.com/* just to rule out the possibility of another subdomain.

What I’d been getting at with setting up some kind of new logging was that I think the only way you can solve this is to gain visibility into those 404s. I’m not sure why logflare wouldn’t capture them.

thanks I am add it now and see how it goes.

seems not affected anything. 404 requests are as many as 200 request…

your are right, I hope there is a way to help get visibility of those 404s…