# Stop staring at dashboards: Let your Go API diagnose itself > Source: > Published: 2026-07-26 11:33:19+00:00 Every Gopher knows the drill: An endpoint gets slow. A spike of 500s appears. You open Grafana. You stare at 12 different panels. You cross-reference Prometheus metrics with traces. You guess it might be GC pressure or a connection pool saturation. **What if your API just told you what’s wrong?** I built `mAPI-ng` because I was tired of the “Observability Tax”: the hours spent configuring OTel, Prometheus, and Grafana just to get basic answers. `mAPI-ng` doesn’t just show graphs; it interprets them. It correlates RED metrics (Rate, Errors, Duration) with Go runtime signals, instance health, and downstream IO. When an endpoint fails, it ranks the most likely causes: Every diagnosis comes with a “Rules this out” line. If the evidence doesn’t fit, it tells you, avoiding the “AI hallucinations” of black-box tools. I’m a “Code Alchemist” at heart—I like things that work out of the box. To instrument your app: No YAML hell. No Prometheus to manage. It uses ClickHouse for high-performance, compact storage. I believe observability should be a right, not a luxury. The entire stack is MIT licensed and self-hostable with a simple make up. If you prefer the “easy mode”, there’s a hosted version at mapi-ng.com (with a forever-free tier), but you’ll never be locked in. If you have Docker installed, you can see it in action with a sample “leaky” API: ``` git clone https://github.com/arhuman/maping cd maping make local make generate-traffic ``` Open `localhost:8080` and watch the diagnosis engine work. I’m looking for feedback from fellow Gophers! Does this approach to “evidence-backed diagnosis” make sense for your workflow? What’s the one thing that always kills your on-call nights? GitHub: [arhuman/maping](https://github.com/arhuman/maping)