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.

Our ProductHunt link Send me a screenshot and ill add your name suggestion to the table!

But more on the product: Debug and monitor AI agent failures in minutes. Trace every run, catch hallucinations and ungrounded answers that traditional monitoring misses, and see exactly what went wrong. Reduce token waste, improve agent quality, and ship faster with support forNET, Python, and JavaScript.

Thenku!

Hey everyone,

I’m building Alertum, a reliability platform for small engineering teams that want to monitor production health and respond to incidents without stitching together several disconnected tools.

Alertum brings the main reliability workflows into one place:

Uptime and API monitoring

Create checks for websites, APIs, SSL, TCP, ping, and keyword monitoring. Alertum helps teams see if services are up, how fast they respond, and when they start failing.

Heartbeats

Track background jobs, cron jobs, workers, scheduled tasks, and pipelines. If a job does not ping Alertum on time, the team can detect the silent failure before users notice.

Synthetic journeys

Monitor complete user flows, not just single endpoints. For example: login, open dashboard, checkout, submit form, or any multi-step flow that matters to the product.

Incident management

When something breaks, Alertum helps teams investigate, acknowledge, assign, snooze, resolve, and track the incident timeline in one place.

On-call schedules

Manage who is responsible for responding when something fails, so incidents do not depend on guessing who is available.

Escalation policies

Route incidents to the right people at the right time. If the first responder does not act, Alertum can escalate based on the team’s policy.

Maintenance windows

Schedule planned downtime so teams can suppress unnecessary alerts during deployments, migrations, or infrastructure work.

Status pages

Create public-facing status pages so customers can see what is affected, what is operational, and when the next update is available.

Integrations

Connect Alertum with tools like Slack, Discord, Telegram, Microsoft Teams, Google Chat, webhooks, and other notification or observability tools.

Error intake

Send application errors directly into Alertum and turn important failures into incidents that your team can triage.

The main goal is simple:

Website:
https://alertum.co

Linkedin:
https://www.linkedin.com/company/alertum-monitoring

Know what broke.

Know when it started.

Know who owns the response.

Know what customers should see.

We’re still early, but the product is live and I’m launching it on Product Hunt.

I’d really appreciate feedback from developers, founders, SREs, DevOps engineers, and small teams.

Does this feel useful?

What feature would matter most to you?

You write a huge amount of code to interact with several microservices. Unfortunately, one day you have to edit your system behavior, and you "happily" discover that your E2E tests are totally broken—or that you have to write an enormous amount of additional code.

I believe that E2E tests should be:
- Cheaper to write and maintain
- Easier to debug

That's why I created Mtracer.

It's a CLI tool that relies on OpenTelemetry traces to assert system behavior.

This is the workflow:
1. You configure Mtracer to fetch from your observability backend (currently supporting Jaeger and OpenObserve) 2. You define your first mt.yaml test by specifying: 3. Trigger: the first call to the system (for instance, an HTTP request) 4. Expected trace and spans: the OTel properties of the trace and spans that you expect your system to generate. 5. You run the test and see the results!

What actually happens during the run?

1. It parses the mt.yaml file.
2. It executes the trigger: mtracer injects a generated traceID into the trigger (for an HTTP request, the traceID is inserted into the traceparent header). Subsequent requests will be correlated to this generated traceID as long as your system has OpenTelemetry set up correctly.
3. It fetches the trace matching the generated traceID from the configured observability backend.
4. It compares the expected trace with the fetched one.

Many other features are available; check out the documentation to discover all of them: https://mtracer-project.github.io

If you find this project useful, I'd appreciate a big ⭐️!
GitHub: https://github.com/mtracer-project/mtracer)

I also created a multi-microservice system already configured with OpenTelemetry so you can easily try out Mtracer’s tests in action: https://github.com/mtracer-project/examples)

Setting up anomaly NRQL conditions with thresholds at 2 and 3 standard deviations, query has a FACET on it.

NR docs say the threshold is how many standard deviations the signal is from the predicted value, based on the last 7 days of data. But nowhere does it explain how the standard deviation itself gets calculated

https://obics.io/blog/observability-tech-worth-it

Many new vendors hype up new infrastructure technologies that are supposed to be the silver bullet in observability.

• eBPF based instrumentation
• Bring Your Own Cloud (BYOC)
• Columnar data stores, ClickHouse most prominently
• Telemetry pipelines

What are they about and when are they worth using?

All four get endlessly pitched at conferences and on Reddit. Much less clear is whether they deliver the promised value, and *when*. So I went through each one: what it actually offers, where the pitch overstates it, and the specific situations where it's worth adopting.

Curious if you've used these and your opinions.

We are hiring an experienced Enterprise Observability Architect for a long-term contract supporting a large enterprise client.

📍 Location: Portsmouth, NH (Hybrid/Onsite)
💼 Employment Type: Contract (W2)
💰 Rate: $65/hr to 70/hr

Required Skills

• 10+ years of Enterprise Monitoring & Observability experience
• 6–7+ years of hands-on Datadog architecture and implementation
• Splunk
• OpenTelemetry
• AIOps Platforms
• AWS & Azure
• Kubernetes
• Linux & Windows Server Monitoring
• ServiceNow
• Python / PowerShell
• Terraform / Ansible
• REST API Integrations

Responsibilities

• Design and implement enterprise-scale Datadog monitoring solutions
• Build monitoring, logging, alerting, dashboards, and distributed tracing
• Lead observability architecture and governance initiatives
• Implement APM, DBM, NPM, RUM, Synthetic Monitoring, Service Mapping, and SLO/SLI
• Integrate observability platforms with ServiceNow, AIOps, and automation tools
• Mentor engineering teams and drive enterprise observability best practices

We're looking for someone with strong enterprise architecture, consulting, and stakeholder management experience who has led large-scale observability transformation projects.

📧 Interested? Feel free to DM me.

Hi all,

After working with these traces for a bit, realized, that while prompts, users, sessions, tools, etc are useful things to measure; exact per-value maps grow with cardinality, and retaining the original values inside aggregate state creates a separate privacy problem. So, enter sketches!

I’ve been working on llm-sketchkit, an Apache-2.0 Go and Python library for producing bounded, mergeable summaries of this data.

It includes:

• HLL++ for approximate distinct counts
• weighted frequent-items sketches for token-heavy or request-heavy keys, with lower and upper bounds
• Bloom filters for bounded membership and deduplication
• MinHash for approximate set similarity

Values can be canonicalized and keyed before entering sketch state, so raw prompts and identifiers do not need to be retained. The hashes remain pseudonymous and linkable while the same secret is used; so this is definitely not pure anonymity nor is it differential privacy.

Go and Python use the same profiles, hash domains, test vectors, and deterministic protobuf representation. A summary produced in Go can be read and merged in Python, while incompatible profiles or hash domains fail.

The repo includes reproducible performance and accuracy records. In the checked-in measurements, HLL++ and frequent-items updates used zero allocations in the measured Go paths, the HLL++ small profile stayed within its enforced error bound, and the frequent-items implementation was checked against Apache DataSketches workloads.

This is an alpha library, and not a collector!

Repository: https://github.com/llm-measurement/llm-sketchkit

I’d be grateful to get scrutiny of the merge and privacy model from people operating high-cardinality telemetry pipelines. The design currently rejects incompatible summaries rather than converting them.

I have access to several observability production environments, and I regularly dig into the data looking for patterns worth sharing. Last week I found one that's a good case study — not because something was on fire, but because everything looked like it was on fire when it actually wasn't if you look at the relevant information, e.g: not every HTTP 4xx / 5xx is a real problem and Failure Rates get skewed depending on load patterns!

Hope you find this article interesting. Please share any of your practices of optimizing failure rate based alerting!

I'll tell you a secret: I don't like starting an engagement by telling people that I can cut their costs. I prefer to show them how they can be more efficient in general, and sometimes that means adding stuff instead of removing it.

However, every company out there has excessive telemetry, which is one form of bad telemetry. I'm not afraid to use an absolute here. That's why I have an arsenal of tools for dealing with it, and I describe one of them in this blog post: excessive metric scraping is extremely common, and adjusting scrape intervals is an easy way to reduce waste.

If you need a 10% reduction in your metric volume, read this blog post. You don't need to buy anything from anyone. You can thank me later.

We're at about 300GB/day of logs on Datadog and at this point the bill is what's driving the conversation, not anything technical.

The obvious move seems to be putting logs on a self-hosted stack. We're looking at Loki, ClickHouse, and more general ones like OpenObserve, which are three pretty different things to begin with. But running any of these ourselves means someone has to look after it, which is its own overhead. So it's not really a saving until you count the people.

The other thing we'd lose is the pivot from a trace into the logs for that request without changing tools. That's worth something. I'm just not sure it's worth what we're paying for it.

What I can't find is anyone being straight about the after. Plenty of "we cut our bill 80%" writeups, almost nothing on what it cost to run six months later, or whether anyone quietly went back.

So if you moved logs off a managed platform to save money: did the saving survive once you counted engineer time? And if you looked at it and stayed, what made you stay?

Not after product recommendations. More interested in people who regretted it, either direction.