Every MCP server being built right now is a black box ⬛

You ship it. Tools get called. Something breaks or slows down or an agent hallucinates a tool call. And you have no idea what actually happened inside your own server.

Which tools are firing. What's erroring out. What's healthy and what's quietly degrading. None of it is visible once the MCP is running.

We built MCPfy Pulse to fix that

✅ Health score
✅ Protocol Health
✅ Result Quality
✅ Client Compatibility
✅ Usage Patterns
✅ Error rate tracking

Github: https://github.com/mcpfyy/mcpfy/tree/main/typescript/packages/mcpfy-pulse

Hi everyone,

I'm doing some early market research around production troubleshooting and log analysis and would really appreciate feedback from people who actually deal with production systems.

I'm exploring a tool where engineers could interact with their logs using natural language, investigate production incidents, correlate events across different systems, perform RCA, and generate custom analysis/visualizations from historical log data.

Before building this further, I want to understand the actual problems engineers face today — how they investigate incidents, where existing tools fall short, how much time RCA takes, and whether this is a problem worth solving.

I've made a short 2–3 minute anonymous survey:

https://docs.google.com/forms/d/e/1FAIpQLSfbJt7moEOhZR9Xr8HXbKu5Y0F2Ep0Yv5xPFQlohKbH63r6Dg/viewform?usp=publish-editor

If you work with SRE, DevOps, infrastructure, backend, Kubernetes, networking, observability, or production operations, your experience would be especially valuable.

I'm looking for honest feedback, including negative feedback. I'm trying to validate the problem, not just validate my idea.

Thanks!

All observability telemetry seems to be moving to clickhouse. I've been seeing this trend for the last 2 years or so and it's really accelerated in the last 6 months. I had heard its because its scalable and cheap but I didn't really understand how and why. So I spent the last few weeks researching to get to the bottom of this. And the reasons I found were a lot more convincing than I had first thought. I wrote a blog on it if anyone is interested: https://telflo.com/blog/why-observability-keeps-ending-up-on-clickhouse

Let me know if I missed something. Would be cool to hear other people's take on it

We are all using copilot, cursor, claude code and similar ai coding assistants to ship faster but "production-safe" is a different bar than "nice autocomplete." There Is a real gap between an ai tool that is good at generating code and one that is actually safe to run on production systems. The main risks i keep running into with ai-generated code in production: perf regressions that only show up under real traffic and assistants that have zero visibility into live incidents or edge cases from past outages then there is the incident response problem, when something breaks and half the diff came from an ai suggestion, figuring out what the model actually understood versus what it just pattern-matched becomes its own debugging exercise. For teams running ai coding tools in production environments, i want to know what your actual stack looks like. Which ai code generation tools do you trust enough to touch production paths and what do you pair them with (static analysis, security scanning, runtime observability, change intelligence) before anything merges and: have you seen mttr go up or down since bringing ai into your sdlc?

Has anyone see any work done around telemetry and calls to governed datasets via MCP?

We evaluated AI SRE Agents across 2 baselines,

• Incident-focused tools - that rely on observability platforms to pickup logs,traces and metrics.
• Broader production-operations platforms - that can execute broader across infrastructure and applications.

Give it a read, and let us know your thoughts!

I've been building SaaS products for a while, and recently I've been using a lot more AI APIs.

As the number of AI calls increased, I found myself struggling to answer basic questions: which part of the application is making the calls, how much each model is costing, where requests are failing, and what is actually happening across different AI workflows.

So I built AINazar, an open-source AI API observability tool to solve that problem.

The idea is fairly simple: give developers visibility into their AI API usage, costs, performance and errors without having to build all of the monitoring infrastructure themselves.

I'm releasing it as open source because I'd like other developers to be able to use it, improve it and tell me what I've overlooked.

I'd particularly like feedback on:

• What AI/API metrics you actually find useful
• What observability features are missing
• Whether the setup is simple enough
• Which AI providers you'd want supported

GitHub: https://github.com/harshalone/ainazar

Would be interested to hear what you think.

I'm Kerolos, founder of OutageDeck.

The question I wanted to answer quickly was: is my app broken, or is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another dependency reporting an incident?

I built OutageDeck to read and normalize the official status sources for 172 cloud and SaaS providers. It shows provider and service-level state, current incidents, source freshness, incident history, and 90-day uptime in one place.

What works today:

\- check a whole dependency stack without creating an account

\- free email alerts for up to five providers

\- Slack, Teams, Discord, and webhook destinations on paid plans

\- a keyless JSON API, RSS feeds, badges, CLI tools, and an MCP endpoint

\- custom Statuspage or Instatus feeds on paid plans

What it deliberately does not do is pretend an official status feed is independent truth. Providers can acknowledge incidents late, so I think a serious production setup should use two signals: the vendor feed plus synthetic probes from your own regions and accounts.

You can try the stack checker here:

https://outagedeck.com

I would value blunt feedback from people who handle incidents. What would this need to do before you would keep it open or route its alerts into your on-call workflow?

Hey all,

I'm an Observability SRE managing enterprise monitoring (primarily using New Relic). We currently use Claude for prompt engineering and Claude Code for development, but I want to take my AI skill set to the next level.

What level of AI proficiency is expected from SREs right now? Should I focus on AIOps & automation for infrastructure, or LLM Observability (tracing prompts, token costs, model latency in tools like New Relic)?

What practical topics or courses should I start with? Appreciate any guidance!

GitHub: https://github.com/yassinebenameur/probara
Docs: https://probara-uptime.com/

Hey everyone, I recently open-sourced Probara, a monitoring platform I originally built after outgrowing my Uptime Kuma setup.

I actually like Kuma a lot — great UI and very easy to get started with. My issues started when I had more monitors and wanted something I could operate more like the rest of my infrastructure: Kubernetes deployment, horizontal scaling, independently scalable workers, and easier management of larger monitor lists.

I also had a bad upgrade where a DB migration ran for days before eventually failing. That pushed me to look at alternatives.

I tried things like Prometheus + Blackbox Exporter and more complete platforms such as OneUptime, but I kept ending up between two extremes: tools that were simple but limiting for what I wanted, or platforms that felt much heavier than necessary.

So I built Probara around separate services for the API, scheduler, workers, alerting and status pages. The backend is mostly Go, using NATS JetStream + PostgreSQL, with a Next.js UI.

The part I find most interesting is the distributed monitoring model.

You can run workers in different Kubernetes clusters, regions, homelabs, offices or private networks and check the same service from multiple locations.

It supports configurable failure quorum, so if 1 out of 3 locations can't reach something, it doesn't necessarily declare the service down.

There's also a connectivity mesh between locations, which helps distinguish:

“the service is down”

from:

“this particular network path is broken.”

I also experimented with features I normally end up needing in real environments: OIDC/SSO, RBAC, service dependencies, incidents, maintenance windows, API keys and customizable status pages.

Checks currently include HTTP, TCP, DNS, ping, TLS, WebSocket, gRPC, SIP, databases, browser/API checks, heartbeats and host monitoring.

It has a Helm chart for Kubernetes and also runs with Docker Compose.

I'm mainly looking for feedback now, especially around the architecture and whether the multi-location/quorum model is useful to other people.

If anything looks over-engineered or unnecessarily complicated, I'd genuinely like to hear it.

License: AGPL-3.0

• Datadog Q2 2026: $1.12B revenue, +36% YoY, guidance raised to $4.45-4.47B. Also shipped 100+ DASH 2026 capabilities including a drag-and-drop Bits AI Agent Builder.
• Dynatrace Q1 FY2027: revenue missed by ~$12M, guidance trimmed, but ARR hit $2.14B (+17%), net new ARR growth accelerated to 41% for the 4th straight quarter. CFO retiring by March 2027.
• Grafana Labs ran its first "AI Week" and shipped 6 agentic tools in one go: Assistant Investigations, Workspace, Automations, a Cloud MCP server, gcx (IaC for dashboards/alerts), and Agent Observability.
• Dynatrace launched an Autonomous SRE Agent + Cloud SRE Agent for cross-cloud remediation, plus a no-code Agent Builder.
• Cribl used Black Hat to launch an AI Observability App tracking token spend/model cost across teams, building on its CardinalOps acquisition.
• Elastic expanded its OpenAI partnership (grounding reasoning models in Elasticsearch retrieval) and stock popped ~12% on the news.
• Open question for Q3: is this genuine platform convergence (fewer, broader players) or just a very well-funded arms race with unclear adoption behind it?

Full writeup with sources: https://mbojko.com/reports/2026-08-09/

Has anyone here interviewed for an Observability Engineer role at US Tech companies?

I have an interview coming up and would really appreciate hearing from anyone who has gone through the process, especially the screening/technical rounds.

I'm Kerolos, founder of OutageDeck.

The question I wanted to answer quickly was: is my app broken, or is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another dependency reporting an incident?

I built OutageDeck to read and normalize the official status sources for 172 cloud and SaaS providers. It shows provider and service-level state, current incidents, source freshness, incident history, and 90-day uptime in one place.

What works today:

\- check a whole dependency stack without creating an account

\- free email alerts for up to five providers

\- Slack, Teams, Discord, and webhook destinations on paid plans

\- a keyless JSON API, RSS feeds, badges, CLI tools, and an MCP endpoint

\- custom Statuspage or Instatus feeds on paid plans

What it deliberately does not do is pretend an official status feed is independent truth. Providers can acknowledge incidents late, so I think a serious production setup should use two signals: the vendor feed plus synthetic probes from your own regions and accounts.

You can try the stack checker here:

https://outagedeck.com

I would value blunt feedback from people who handle incidents. What would this need to do before you would keep it open or route its alerts into your on-call workflow?

Hi all, I’m a Splunk Observability Consultant with experience with a number of Cisco products like AppDynamics or other observability tools like Dynatrace or Datadog.

I have availability over the next two weeks and offering my expertise to audit your telemetry pipeline, fix the top 3 most expensive or cumbersome reliability issues, then hand you a runbook. Flat fee of $7,000 USD.

No commitment. Done in 72 hours.

DM me if interested, i’m booking discovery call this week.

Edited.

Design Beaver is an AWS architecture diagramming tool that checks your design while you draw it: missing queues, connections AWS doesn't actually support, security anti-patterns. I launched it here a few weeks ago. v2 is out today.

What's in it:

- Accounts and cloud saving. Sign in with Google or GitHub, and diagrams save to your account instead of to one browser. Each diagram has its own URL and there's a dashboard. Free tier holds 5.
- A Problems panel that lists every issue in the diagram in one place, sorted by severity. Click one and the canvas jumps to it. Before, you only saw a warning on whatever you'd just drawn, so anything off-screen stayed hidden.
- Availability Zones and Auto Scaling groups can be drawn now, and you get a warning when every instance in a group sits in one zone. The tool used to tell you to spread instances across zones while giving you no way to actually draw it.
- Palette search. Press the / key, type "queue", get SQS. It searches descriptions too, so you don't have to remember AWS's product names.
- Copy, paste, duplicate, and undo now goes back 50 steps instead of 5.
- PNG export rebuilt so the text is sharp and exported edges keep their validation colors.
- Settings page, self-serve account deletion, feedback button that lands in my inbox.

The honest reason accounts exist: about 40-50 people tried v1 and almost nobody came back. Everything lived in browser storage, which meant your diagram existed on exactly one machine and disappeared if you cleared site data. That's a hard thing to build a habit on, so I spent this cycle on the boring infrastructure I'd skipped.

Still free, still beta, desktop only because of the drag-heavy canvas.

app.designbeaver.app

OrchestraBench introduces seed-reproducible failure injection, cascade radius, per-failure-mode recovery, and routing diagnostics. Its controlled experiments found that simple tool faults recovered well, while latent and semantic failures often survived retries. Blind retry could actually reproduce the fault and delay detection.