From production alert
to a ready PR

AppGlass watches your connected services around the clock and starts investigating when an issue appears. It gathers context, tests suspected causes, and prepares a proposed fix as a pull request when the findings support one. It also checks releases during controlled rollouts and answers questions about production behavior through Slack. Your team gets findings and supporting evidence to review.

AppGlass brings automatic investigations, dynamic production checks, and proposed fixes together in a ready-to-use workflow. Building your own means owning the integrations, investigation logic, runtime tooling, access controls, and ongoing maintenance. With AppGlass, you start with an existing investigation workflow and built-in Continuous Debugger, then configure it for your services and team.

Our key differentiator is dynamic hypothesis testing through our built-in Continuous Debugger. AppGlass combines observability, source code, Slack, and internal knowledge, then requests additional evidence directly from the running application when needed. It can inspect variable values, evaluate read-only expressions, and check execution paths. Each finding helps confirm, rule out, or refine a hypothesis and determines what to check next.

AppGlass works alongside your existing observability and development tools. Start with the alert source and code repository relevant to your first service. Connect Slack and internal knowledge to add team discussions, runbooks, and past incident context. The pilot is scoped to the connections needed for your first use case.

Production inspection works on JVM services: the AppGlass agent attaches to a Java process, so applications written in Java and other JVM languages are supported. Support beyond the JVM is not available today.

You attach the AppGlass agent to the service you want to inspect and run the control plane, either in your Kubernetes cluster or on any machine with a JVM. Alongside that, you connect the tools the investigation reads from: your alert source, code repository, and optionally Slack and internal documentation. Setup steps for Kubernetes, standalone environments, and local IDE attach are in the documentation.

Continuous Debugger collects runtime evidence without suspending application threads. Runtime observation is read-only. Performance overhead depends on how often a check runs, how much data it captures, and the expressions evaluated. Targeted conditions and capture limits help manage that overhead; assess it on the selected service during the pilot.

Your team defines the investigation scope and access permissions. Collection filters and masking rules help exclude or redact sensitive runtime data, while role-based access and audit logging control access to captured evidence. The runtime control plane can run in your infrastructure. Data routing and AI processing requirements are agreed as part of the AI SRE pilot setup.

Your team reviews and decides whether to merge proposed pull requests. Deployments run through your existing pipeline. AppGlass takes rollback actions only when your team has explicitly configured a policy for a controlled rollout; otherwise, it reports the regression and its evidence. When evidence is insufficient to confirm a cause, the investigation makes that uncertainty clear.

Yes. AppGlass can provide runtime investigation capabilities to compatible agents through MCP or skills. Your agent can request targeted observations and use the resulting evidence in its own workflow. Choose AppGlass AI SRE when you want the integrated investigation experience, or connect AppGlass runtime tooling to an agent you already operate.

Request a demo to choose your first use case and scope an early-access pilot. Together, we select a service, agree on connections and permissions, and define what a useful investigation should deliver. Your team reviews the findings before expanding the scope. No installation is required for the demo.