On day 3 of the hackathon, I compared Opus 4.8 and Sonnet 4.6 using the gcx tool and debug-with-grafana skill to diagnose a fault-injected failure in the OpenTelemetry demo. Both models pinpoint the root cause correctly, while Sonnet proves cheaper for straightforward issues. And an reflections after 3 days, on how skill files and the right context make AI-driven observability much more effective.

Day 2 of the hackathon. I used the Grafana gcx debug-with-grafana skill with Claude to find the root cause of failing and slow services from metrics, logs and traces, and monitoring Claude’s own token usage and cost with OpenTelemetry. And the team outing with Quad driving and paintball.

Day 1 of the OpenValue hackathon in Belgium. I explored AI tooling and got hands-on with gcx, Grafana’s Observability as Code CLI tool.

Incident reports are often static and lack the detail needed for deep analysis. What if you would use Observable Framework to create interactive, data-driven incident reports. By using customer impact data from DownDetector, you can build reproducible and interactive incident reports that clearly share your line of thinking.

An Application Observability Code Challenge with virtual threads. Spot the difference between system thread and virtual thread usage for the same application with some problems.

The third and final day of the hackathon. During this hackathon I learned a lot about Quarkus, LangChain4j, Grafana MCP and many other things. Read this blog to read the progress of the last day and my conclusions of the hackathon.

The second day of the hackathon was a mix of activities. Next to the hackathon, we had a climbing outdoor activity. In this blog post I will share the results of the hackathon on day 2 and some pictures of the climbing activity.

Together with my colleagues of OpenValue Utrecht we are having a hackathon at a nice place in the south of Belgium. The goal of the hackathon is to build a monitoring buddy, a chatbot that can help you with your monitoring and observability questions. I will use Quarkus, LangChain4j, Tools and MCP in combination with Observability to build this chatbot. This blog post describes the progress on Day 1.

The first of the Application Observability Code Challenges step by step revealed. The application has some unexpected behaviour. In this post I will explain step by step what you can learn from the metrics and how you can improve the observability of the application to finally find the real problem.

The first of the Application Observability Code Challenges is now available. A simple Spring Boot application with a REST endpoint implemented in Jersey/JAX-RS This application has some unexpected behaviour. Can you find out what is happening based on the observability data? Can you improve the observability to prove that a fix really fixed the problems?