But the 200 GET requests (workers subrequest) is the GET cache hit when the request is turned into a GET for the caching on the worker.

Hey, so it’s not malicious but it can be definitely seen as confusing.

I usually see these with originless workers or when a method/route isn’t explicitly handled which can result in a 504

Thanks so much, so it's all part of Cloudflare internal Worker processes and they're legitimate ( I guess that's why you label them with

Workers Subrequest

huh 😉 )

A general logs question (not specific to instant logs). How do bulk redirects (https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/concepts/) are being marked in logs? Is bulk redirects list item id that matched is provided in the logs? I need to get daily redirect counts for each bulk redirect list item, I wonder if bulk redirects + logs can achieve this. We are on enterprise plan. Thanks!

Anyone has any ideas on this? Thanks!

AFAIK there is no special marking for redirects done by bulk redirects vs other redirects. Both types of redirects will have the appropriate

EdgeResponseStatus

code issued for that redirect in the logs (301, 308, etc). What you can do is head to analytics, filter by that path and see the number of status codes being 3xx.

No easy way if you've got a big list of paths unfortunately.

Feel free to reach out to your account team as well and see if they can raise it with the bulk redirects team.

Thanks a lot, @cole | data !!

Instant logs doesn't appear in our dashboard

how do I make it appear?

Please don’t tag, especially on weekend. If you have a business or enterprise zone you will find it under the analytics section on your zone.

Hello, Can you please check below to see if it's correct way to filter for example this IP (1.1.1.1)?

curl -X POST 'https://api.cloudflare.com/client/v4/zones/XXX/logpush/edge/jobs' -H 'X-Auth-Key: XXX' -H 'X-Auth-Email: XXX' -H 'Content-Type: application/json' -d '{ "fields": "ClientIP,ClientRequestHost,ClientRequestMethod,ClientRequestURI,EdgeEndTimestamp,EdgeResponseBytes,EdgeResponseStatus,EdgeStartTimestamp,RayID", "sample": 1, "filter": "{\"where\":{\"and\":[{\"key\":\"ClientIP\",\"operator\":\"eq\",\"value\":\"1.1.1.1\"}]}}", "kind": "instant-logs"}' | jq .

The filter field needs to be json escaped otherwise looks right to me.

Thanks Cole! what about below?

Looks good to me!

Thanks cole. You are amazing.

Hello, I have a feature request. with logpush, is it possible to allow filtering by an array[object]? for example, with my worker logs, I want to be able to filter if there's an 'Error' in my Logs key. Unfortunately this doesn't work with the current filter https://developers.cloudflare.com/logs/reference/filters/ https://developers.cloudflare.com/logs/reference/log-fields/account/workers_trace_events/

cclients

Hey! Is this still planned/being worked on? Any estimate of when it might become available?

Hi Albert, unfortunately don't have an update on ETA yet although we've been making progress on some of the necessary infra work to do this

It would be amazing to be able to add additional custom fields derived from custom hostname metadata in both Logpush jobs & Instant Logs -- Would make searching/filtering for e.g. individual customers a lot easier 🙏

Do you have an example of what that would look like?

I'd envisaged something building off the existing rules language to add new 'freeform' logpush fields using expressions, e.g. New field:

customerId

, value:

lookup_json_string(cf.hostname.metadata, "customerId")

, or alternatively a new option alongside Request/Response Header/Cookies that is 'Hostname Metadata' or similar, that just takes a key to lookup from the hostname (e.g.

customerId

) Similarly, the filters on Logpush jobs could have a similar interface. We have some good information in our hostname metadata (application the host belongs to, the defined security policy that we target rules against etc.) so it would be really useful to have that when ingested into our Elasticsearch. We also have some very high log volume hosts that we don't need the logs for that we could exclude if the filters supported the expression language (using a metadata field of e.g.

logpush: false