How to build workflows that catch bugs early and keep code moving

Observability isn’t just about collecting data. It’s about connecting the dots across your stack to answer why something is broken, not just what is broken. For developers, this means the ability to ask ad-hoc questions about live systems and get answers fast enough to change code with confidence.

Modern observability tools can help you catch issues before they become incidents, validate deployments, and understand how your code behaves in the real world. This excerpt from our new Developer’s Guide to Observability, walks you through how to build an observability workflow that works for you, not against you.

Bring observability directly into your IDE

Modern integrations—like the Dynatrace Live Debugger for VS Code and JetBrains IDEs—make it possible to inspect live workloads, trace requests, and debug production issues without leaving your editor.

Here’s what a good IDE integration should let you do:

• Live debugging breakpoints: You can set breakpoints in your code that apply to running instances in selected environments. These are non-breaking and won’t interrupt runtime behavior.
• Environment filtering: You choose which environments and instances to debug, so you’re not overwhelmed by irrelevant data.
• Snapshots: You should be able to view snapshots displaying:
  • Local variables
  • Stack traces
  • Process metadata
  • Tracing data
• Debug without redeploys: Get instant access to code-level debug data in production so you can pinpoint issues faster, avoid service disruption, skip redeployments, and eliminate the need to recreate costly defect environments.
• Bring agentic AI into your IDE: Use MCP to integrate your observability platform’s AI capabilities into your AI coding agent to get immediate performance and security insights about your code base without ever leaving your IDE.

Build a launchpad that works for your team

Start by creating a simple, centralized view that gives you quick access to the tools and data you use most. This could be a dashboard in your internal developer portal, a pinned tab in your IDE, or even a custom homepage in your observability platform.

Include links to:

• Your service’s health and performance metrics
• Logs and traces for recent deployments
• CI/CD status
• Source code and issue tracking

Why it matters: You shouldn’t have to dig through menus or memorize URLs to find what you need. A personalized launchpad saves time and keeps you focused.

Surface observability in your service catalog

If your team uses an internal developer portal like Backstage, Port, or Humanitec, make sure observability data is embedded directly into the service catalog. When you look up a component, you should see:

• Where it’s deployed
• Whether it’s healthy
• Any recent problems or vulnerabilities

For example, for Kubernetes-based services, observability should surface deployment status, pod health, and cluster-level metrics directly in the catalog view.

Why it matters: You already use the catalog to find ownership and repo links—why not also see how the service is performing? To learn more, checkout our Backstage spotlight.

Automate validations in CI/CD

Every time you deploy, your pipeline should automatically verify that your service meets basic observability standards. Are logs and traces being captured? Are synthetic tests passing? Are performance thresholds being met?

Set up automated validation checks such as Quality Gates that run on every code check-in, flagging issues before they reach production. This will provide a continuous feedback loop on the health of your platform. Just remember: The value of that loop depends on the quality of the checks you put into it.

Why it matters: You don’t want to find out after the fact that your service shipped without telemetry or broke a key performance metric.

Surface observability in pull requests

When you open a pull request, you should get feedback not just on code quality, but on how the change affects your service’s behavior. Did it introduce a regression? Did it break a test? Did it exceed latency thresholds?

Integrate observability validations or automated feedback directly into your Git workflow.

Why it matters: You spend a lot of time in PRs—this is the perfect place to catch issues before they merge. Learn more about SDLC Observability.