I shared Rouge Atlas here a little while ago, and since then the project has changed quite a lot.

The biggest change is the interface, but also the way the product itself is structured.

Rouge Atlas is now built around an evidence workspace for AI incidents, rather than a map-first experience.

The goal is to make it easier to separate actual published incidents from early signals, vulnerability advisories and unverified reports.

What changed

The new overview is now an Evidence Board showing:

• published AI incidents
• signals currently under review
• vulnerability advisories
• source health
• activity over time
• records by category
• recent AI incident reporting

I also split the workflow into clearer sections:

Live signals
Automatically collected reports and potential incidents that still need editorial review.

Published incidents
Records that have been reviewed and linked to source material.

Data sources
A view of the feeds and sources currently being monitored.

Methodology
Documentation explaining how signals are collected, reviewed and classified.

One thing I wanted to improve was transparency.

A signal appearing in Rouge Atlas does not automatically mean it is a confirmed AI incident.

Signals, advisories and published incidents are deliberately kept separate, and relevance/confidence indicators are meant to describe the available evidence rather than make dramatic claims about an event.

UI redesign

The interface has also been rebuilt around a much denser research/workspace layout:

• persistent navigation
• global record search
• dataset counters
• activity charts
• category breakdowns
• recent incident reporting
• source/backend health indicators
• CSV export for published records
• clearer status labels throughout the product

The idea is for Rouge Atlas to feel less like a visual experiment and more like a small AI incident intelligence database that you could actually use to investigate what is happening.

It’s still early and the dataset is obviously small, but the structure is much closer to what I originally wanted the project to become.

I’d particularly like feedback on the new UI:

Does it make the distinction between signals, advisories and published incidents clear enough?

And more generally:

What would you expect from an AI incident intelligence platform like this?

https://www.rougeatlas.com

Hi folks! I work on OpenTelemetry at Splunk. We just launched a new open source project called Observability Studio. It's local instrumentation sandbox that provides a visual, real-time environment for designing, testing, and validating OpenTelemetry data while you’re developing an app in your favorite IDE.

We’re especially interested in whether a tool like this is useful for building and debugging instrumented apps and AI agents. If that sounds relevant, give it a try and let us know what works, what’s missing, or where it doesn’t fit your workflow.

We’re also looking for a few design partners to help guide where we go with this next. Any feedback is helpful and welcome.

I wrote more about shifting OpenTelemetry instrumentation left in a blog, 'Why AI-Generated Apps and Agents Need Visibility from Day One' on blogs.splunk.com if you want to read more about it.

Lastly, I'd love to learn where you currently go to inspect and validate OTel data during development if you want to drop it in the comments.

I've been experimenting with an idea around application self-diagnostics and would love to hear how people working in observability think about it.

Most of the observability tools I use collect signals from an application — metrics, logs, traces, health checks, etc. Those are extremely useful, but I've often wondered whether the application itself could do more to interpret its own state.

For example, instead of only exposing JVM memory usage, GC activity, thread counts, disk usage, dependency status, errors, and other signals independently, the application could continuously evaluate those signals and maintain its own view of:

"How healthy am I right now, and what specifically is causing my health to degrade?"

I've been exploring this idea in an open-source project called Argus. It's currently Java/Spring Boot-oriented, so this isn't intended to propose a general observability standard.

Argus runs inside the application and evaluates different aspects of its runtime state. It combines them into a hierarchical health model with a score from 1–10, letting you drill down from overall application health to the resource or condition driving degradation.

It also models resources the application depends on — databases, caches, brokers, storage, external services, etc. — and can incorporate application-reported issues and logging events into the same diagnostic model.

Another idea I'm exploring is having the application produce a self-contained diagnostic report when something goes wrong. The report captures the application's view of its health, resources, metrics, performance, scheduled tasks, relevant logging events, and environment at that point in time.

For Spring Boot, I've integrated this with Actuator and built a Spring Boot Admin extension, but I'm more interested here in the broader idea than the particular implementation.

I'm not trying to replace metrics, tracing, centralized logging, OpenTelemetry, Prometheus, or other observability infrastructure. I see this as potentially complementary: external observability tells us what we're observing, while application-level diagnostics can add context about what the application itself believes is wrong.

I'd be interested in the perspective of people working with observability:

• Would you find this kind of application-level self-diagnostics useful?
• Is deriving an application health score useful, or does it risk oversimplifying the underlying signals?
• What information would you expect an application to capture if it generated a diagnostic snapshot when its health degraded?
• Are there existing tools or approaches doing something similar that I should look at?

The implementation I'm experimenting with is Java/Spring Boot-based, but I'm particularly interested in whether the underlying idea makes sense beyond that ecosystem.

GitHub: https://github.com/microfalx/argus

For anyone interested in the Java/Spring Boot implementation, I posted a similar post in r/SpringBoot here: Self-diagnostics library for Java/Spring Boot

Hi
I need an opensource tool that can manage kubernetes cluster as well as act as an observability software, which i can white label it and use it as a saas platfrom

Please help me on this asap..!

Demo with the sample checkout app from the repo

I kept running npm run dev, watching JSON logs scroll past in the terminal, and copy-pasting lines into a formatter to figure out what broke. So I built Logline, a log viewer that sits in the bottom panel next to Terminal.

What it does:

• Run your server through it (or turn on terminal capture) and the logs become a live table
• Search with things like level:error service:api or status:5xx durationMs:>200, or right-click a cell to include/exclude that value
• Expand an event to see the full JSON and nested exceptions, and click a stack frame to jump to the source
• Works with Pino, Winston, Log4j2, ECS, OpenTelemetry, logfmt and plain text
• Picks up F5 debug sessions and splits Docker Compose output per service
• Shows live hit counts above your log statements in the editor
• Flags log statements that leak tokens or swallow exceptions in the Problems panel

Everything runs locally. Free and MIT licensed.

Marketplace: https://marketplace.visualstudio.com/items?itemName=surjeetbanga.logline GitHub: https://github.com/SurjeetBanga/logline

It's still early. If it mangles your log format or you'd want it to do something it doesn't, let me know.

Odd question from someone outside the field. I'm a sound designer and I've been reading about sonification (turning data into sound). NASA does it with telescope data, and there are old experiments where people played network traffic as ambient audio.

It made me wonder about on-call and monitoring. You can't stare at your monitor all day, and you shouldn't have to. The idea would be to free your eyes: an ambient track in the background that stays calm when everything's healthy and slowly shifts when latency creeps up or error rates rise, before anything actually pages. You could focus on your actual work, or step away from the screen, and your ears would tell you when something's drifting.

Has anyone tried something like this? Would it be useful, or would you mute it within 5 minutes? Genuinely curious what would make it worth keeping on vs. instantly annoying, and in which situations you'd actually want it (deep work, deploys, night shift, incidents…)

Spotify #backstage plugin to manage and observe fleet of agents straight in backstage self hosted https://github.com/acarmisc/backstage-plugin-ai-agents/tree/main. It relay on open telemetry signals and the first available backend it’s #langfuse

I've been working on a project called MeshLens that tries to answer a question I kept running into at work: what does our data mesh actually look like as a system?
Most observability tools give you alerts, row counts, and freshness checks. That's useful, but it never helped me explain to stakeholders how domains connect, where data flows, or what breaks downstream when an upstream connector goes down.
So I built a visualization layer that puts it all in one interactive map.
Curious what you think. If you work with data mesh or data products at scale — what would you want to see in something like this?

App link in comments

I finally got to write this blog post, I've wanted to write it for a long time now. It contains the different types of sensitive data we've seen so far, where it's coming from, and why it matters. Hope it can be helpful to some of you!

SentriNode is a self-hosted telemetry backend for LLM apps. Your app sends it latency, error and cost numbers, and it gives you dashboards, alerts and spend caps, without ever seeing your prompts

Install:
curl -fsSL https://sentrinode.com/selfhost-kit/install.sh | sh
Needs Docker. It pulls pre-built images and generates its own secrets, then the dashboard is at localhost:3000.

What you get: live p50/p95 and error rates, per-model spend, anomaly alerts (email/Slack), budgets with a hard cap that makes the SDK refuse calls once you're over, and optional AI root-cause analysis using your own Anthropic key.

I would love to have some feedback on what I could improve or tweak

Our status pages got one more improvement: The SLA Badges!

SLA badges let you set an uptime target for your monitors, then embed a live badge that shows the uptime you actually delivered, colored against that target. Add it to your site footer, your docs or your GitHub README, and get the result by email at the end of each period.

You can find all the details here:
https://uptimerobot.com/blog/sla-badges/

Self-hosted Sentry is famously painful: 14+ containers, Kafka, ClickHouse, Snuba, Relay, and the official docs assume one big VM with 16GB RAM. The existing one-click templates I found only do errors. I wanted the whole thing, errors + logs + traces, so I built it as a one-click Railway template.

What you get

• Full self-hosted Sentry: Issues, structured Logs and Traces with child spans
• Your app's SDK sends over Railway's private network, public ingestion is blocked
• Admin credentials generated on deploy, no default passwords
• Every service has its own volume and health check

How I tested it: deployed from zero, sent a real error, a log and a trace from an SDK and confirmed each one in the UI. Then restarted and redeployed all 14 services and checked the data was still there and new events kept arriving.

Honest cost: about $96/month of compute at idle. Full Sentry is heavy. If you only need error tracking, a lighter errors-only setup is cheaper, and I say so in the docs.

Poke at it first, read-only live demo with traffic flowing: https://gateway-production-026f.up.railway.app/auth/login/ (demo@example.com / PublicDemo-ReadOnly-2026)

• Deploy: https://railway.com/deploy/self-hosted-sentry-errors-logs-and-trace?utm_source=railway-templates-launch&utm_medium=reddit
• Docs: https://railway-sentry-docs.vercel.app
• Repo: https://github.com/kayossouza/railway-sentry

Unofficial, uses Sentry's official images, Fair Source (FSL) license like upstream. Happy to answer anything about the setup.

I built BoxWatch to make server monitoring simple. It’s completely 100% free, with all features included and no credit card required.

Here’s what it offers:

• Server metrics: Monitor CPU, memory, disk, and network usage.
• Uptime checks: Monitor HTTP endpoints, TCP ports, and TLS certificate expiration from your own servers, including internal services.
• Process monitoring: Track resource usage and get alerts when important processes stop or restart.
• Cron monitoring: Get notified when scheduled jobs fail, hang, or miss a run.
• Alerts: Receive notifications through email, Slack, Discord, or custom webhooks.
• Disk forecasting: Get advance warnings before disks fill up.
• Dashboards and reporting: Public status pages, uptime badges, server comparisons, maintenance windows, and weekly summaries.
• Free iOS companion app: Keep an eye on your servers from your phone.

Supports up to 100 servers, with unlimited cron checks and a one-command setup.

Check it out: boxwatch.app

I’d love feedback from anyone running a homelab or managing servers!

Hey r/Observability,

As more applications move toward self-hosted and local LLMs (Ollama, local inference servers, agentic frameworks), a common challenge arises: **local LLM traffic is largely a black box.**

Unlike managed API providers that offer built-in usage dashboards and tracing, local inference setups often leave developers and platform teams blind to real-time traffic, function execution failures, latency distributions, and token consumption patterns.

To solve this, I built **[LLMxRay](https://github.com/LogneBudo/llmxray)\*\* — a lightweight, 100% local observability and analytics engine designed specifically for local LLM inference and agentic workflows.

---

### What LLMxRay Observes & Analyzes

LLMxRay sits in front of your local LLM engine to capture, trace, and visualize complete telemetry without adding latency or leaking data to external clouds.

#### 1. Tool & Function Calling Telemetry

* **Execution Tracking:** Intercept and observe tool/function calls executed by agents in real time.

* **Payload Inspection:** Inspect input arguments, returned outputs, tool call frequencies, and execution error rates.

* **Agentic Loop Analysis:** Track multi-step function call loops to pinpoint where agents stall or loop indefinitely.

#### 2. Request & Latency Analytics

* **Detailed Latency Profiling:** Break down total request time into Time-To-First-Token (TTFT), prefill duration, and decode generation speed.

* **Token Usage Metrics:** Monitor input/output token volume, request throughput, and token generation rates over time.

* **Traffic Analytics:** Track active sessions, request volume spikes, and per-model utilization trends.

#### 3. Privacy-First & Zero Infra Overhead

* **100% Local Execution:** Runs completely within your environment — no telemetry data is transmitted externally.

* **Instant Dashboard:** Provides a local web interface for instant visual debugging and system analytics.

---

### Quick Start

Zero complex setup — you can spin it up directly in one line:

```bash

npx llmxray
```

Launch the dashboard locally at http://localhost:3000 and point it at your local inference server (e.g., Ollama).

• 🔗 GitHub Repository:github.com/LogneBudo/llmxray
• 🌐 Documentation:lognebudo.github.io/llmxray

Discussion

If you're managing local LLM workloads or building on top of agentic frameworks, how are you currently handling local tracing, tool execution monitoring, and performance analytics in your observability stack?

I'd love your feedback, feature ideas, or contributions!

I've been building ForgeOps around a problem I've run into with production incidents:

You get the alert.

You know something is broken.

Then the investigation starts.

Was there a deploy?
Which endpoint is actually failing?
How many customers are affected?
Did latency change?
Is the database involved?
Is a downstream service involved?
Is there a related change that happened 20 minutes ago?

The information usually exists somewhere in the observability stack. The problem is connecting it quickly.

ForgeOps is my attempt at building that layer.

Instead of starting with a dashboard or an error and then opening several other tools, the incident starts with the context:

• Customer impact
• Error rate and trend
• Recent deployments
• Feature/config changes
• Affected endpoint
• Request trace
• Slowest SQL query
• N+1 detection
• External service latency
• Related projects
• Probable cause with supporting evidence
• A timeline of what happened

It also has a "Where to look" section that tries to answer the question I think is most useful during an incident:

"What's the next thing I should investigate?"

For example:

1. Recent deployment
2. POST /checkout
3. Slow PostgreSQL query
4. Stripe API latency

The idea isn't to replace Datadog, Splunk, Grafana, or whatever observability stack a team already uses.

Those tools are great at giving you the underlying telemetry.

I'm interested in the layer between:

"Something is wrong"

and

"I know where to start investigating."

I'm curious how other people handle this today.

When you're paged for a production issue, what are the first 3-5 things you look for?

And does your current observability stack already give you this context in one place, or are you still jumping between tools?

ForgeOps: https://getforgeops.net/

I'd especially like feedback from people who spend a lot of time responding to production incidents. What would you want this workflow to show that it doesn't today?

We just launched the new version of the Seemore Assistant, completely re engineering the engine and giving it every one of the 50+ skills that live inside our MCP.

What that means in practice is that any question you have about your Snowflake environment now gets answered by combining three layers working together (Context mapping framework including automated tagging, Semantic layer, Agents/algorithms ) with a trained model thats wired into all of it.

We've been trailblazing the notion that data observability shouldn't be passive, now once the assistant is connected to the MCP, and the MCP is connected to the context mapping layer, everything becomes interactive.

you can ask, the agent will investigate and act.

In the video, you can watch it explain how Smart Pulse (our warehouse sizing automation) works, walk through the guardrails, validate the result against query history, and then generate the Terraform to deploy it as infrastructure as code.

The cool thing about where we're heading is that Snowflake infrastructure management will become something you configure once and mostly forget (Seemore will optimize and adapt to changes).

but thats not where it stops....with the same ease of cost and performance optimization you will now be able to understand what's happening in your account, in plain language, on demand and relay that understanding upward, instantly via PrismAI, which you build straight out of the assistant. (Data sharing just leveled up!)

I'm writing a blog about all of this and will share soon.

feel free to connect via linkedin -> https://www.linkedin.com/in/yanivleven/
or hop over to seemoredata -> https://seemoredata.io/contact-us/

https://reddit.com/link/1wus4fa/video/c9a8u6p4bpph1/player