I had tried it like this too, but had the same problem: ``` [env.dev.observability] enabled = true h
I had tried it like this too, but had the same problem:
TIs this just in the dash drawer? That looks like a visual bug. It seems to be disabled correctly. Can you DM me your account id and worker name please so I can check for you 
Xhmm, I still see the logs, it's not until I manually disable it in the UI that comes into effect, account id sent
Mhey guys - i'm not sure if this is the right channel, but i was wondering how to get the tail worker working in local dev?
TTail doesn't work right now in local dev, best to test it in prod!
Mtoo sad 
But thanks for the reply!
But thanks for the reply!
Rwe recommend using Workers Log as its better supported now
-Can I access the content of Workers Log via API the same way as they are displayed in the dashboard?
Kwhat's the retention period for the worker obs logs?
ZAssuming you're talking about workers logs, 7 days as per https://developers.cloudflare.com/workers/observability/logs/workers-logs/#limits
Rnot yet, we're working to make that available!
-Will be waiting for that to happen!
Mare there any alternatives to the js implementations for opentelemetry? i find the existing lib a little heavy for what it provides
TIs there a known issue for workers obs logs not working for Next.js apps running on workers using OpenNext? I've got 2 workers, both with observability enabled, and the one running Next.js does not show any logs.
SAny example on to setup new relic with cloud flare workers to have traces of all outbound comunication?
D+1 that this update ^ is weird, cc @rohin
Not seeing subrequests, wfp requests, tail logs etc in the same place is a step backwards with the new UI
Not seeing subrequests, wfp requests, tail logs etc in the same place is a step backwards with the new UI
Rhey @ebar0n, thanks for surfacing this! We're on it. Hoping to get a quick fix in asap soyou can continue to use real-time logs with WFP. We are also looking into longer-term solutions like using Workers Logs with Workers for Platforms.
Rfor now, the requestId matches the rayID. You can fetch the ray ID from the request header:
const rayId = request.headers.get('cf-ray');
Yhi, wondering if the new workers logs is supporting console.log only or it will also pickup console.error?
IIt should pick up console.error as well.
TI got screwed
TWhy cant I add my newest joiner to the team to Baselime?? @boristane 
TSince the new "cloudflare logs" banner got added
TNo email is being sent when we invite, or when he requests to be added to team
TThere is literally no way to add new people
- also CF logs sucks compared to Baselime... Viva Baselime!
DJust wanted to pop in and say Workers Logs are amazing! Huge fan.
MMy worker has suddenly stopped logging anything except logs related to errors. Only things I remember changing are setting up a bulk redirect (image 2) and adding the "Redirect from WWW to Root" template to my zone.
MNo new deploys at the time the logs stopped logging
Mwrangler tail sees them, so not sure what's up
WHmm I see the same
WRaising
MCheers
M19:23:24 UTC was my last normal log event
TStrongly disagree... I just want Baselime back
WWe're in a resolved state now, thanks for the report!
https://www.cloudflarestatus.com/incidents/5l0zb11llvsw
https://www.cloudflarestatus.com/incidents/5l0zb11llvsw
MThanks!
DWhat’s Baselime?
TBaselime
Use logs, metrics, distributed tracing and wide-events to detect, diagnose and resolve issues before they impact your users.
DOh. Yeah, I don’t trust small third parties like that with all my data.
Tlol, "small 3rd party" that got acquired by CF and is literally the team building CF logs
Tyou didn't even click the link dude 
DI did not. I only looked at the preview.
DI still wouldn’t use it until it’s integrated into CF.
Tmissing out. it's way better of a UX & DX standalone 
Ihello, first of all kudos on workers logs, incredibly useful, love it simply works with console.
I'm trying to get more detail on errors logged like with uncaught exceptions, I tried like this but can't get the stack trace to use source maps:
Is there a way to get the stack using the source maps the same way it works for uncaught exceptions? Or maybe u recommend logging errors in a different way?
I'm trying to get more detail on errors logged like with uncaught exceptions, I tried like this but can't get the stack trace to use source maps:
Is there a way to get the stack using the source maps the same way it works for uncaught exceptions? Or maybe u recommend logging errors in a different way?
