Digma Developer Guide
  • Welcome to the Digma Docs!
  • What is a Continuous Feedback platform?
  • Digma Quickstart
  • Installation
    • Local Install
      • Local Install Architecture
      • Installation Troubleshooting
    • Central (on-prem) Install
      • Resource Requirements
  • INSTRUMENTATION
    • Instrumenting your code for tracing
    • Java
      • Automatic Instrumentation in the IDE (IntelliJ)
      • Spring, Spring Boot, Dropwizard
        • Instrumenting your code in CI/Staging or the terminal
        • Instrumenting your application in Docker Compose
        • Instrumenting your application on Kubernetes
        • Covering more of your code with Observability
        • Using GitHub Actions (beta)
        • Using Micrometer Tracing (Spring Boot 3.x only)
        • Instrumenting code running in CLI
      • Quarkus, Micronaut, OpenLiberty
    • .NET
    • Correlating observability and source code commits
    • Sending Data to Digma using the OTEL Collector
    • Sending Data to Digma Using the Datadog agent
  • Use Cases
    • Design and write code more efficiently by understanding the system flows
    • Get early feedback on bottlenecks and code issues
    • Prioritize Technical Debt
  • Digma Core Concepts
    • Environments
    • Assets
    • Analytics vs. Issues
  • Digma Features
    • Issues
      • Suspected N+1
      • Excessive API calls (chatty API)
      • Bottleneck
      • Scaling Issue
      • Session In View Query Detected
      • Query Optimization Suggested
      • High number of queries
      • Slow Endpoint
    • Analytics
      • Top Usage
      • Request Breakdown
      • Duration
      • Code Nexus
      • Duration Breakdown
      • Endpoint Low/High Usage
    • Performance Impact
    • Test observability
    • Issue Criticality
  • Sample Projects
    • Spring Boot
  • Troubleshooting
    • Reporting Plugin Issues
    • Digma Overload Warning
Powered by GitBook
On this page
  1. Digma Features

Issue Criticality

PreviousTest observabilityNextSpring Boot

Last updated 1 year ago

Over time, Digma may find numerous issues related to your code, however not all issues are equal in impact and priority. Trying to handle all issues at once may result in micro-optimization that will not yield meaningful and effective results.

To help deal with that concern, Digma calculates a criticality score for each insight. The insight criticality is calculated differently for local vs. shared environments and is intended to provide a good indication of which insights are worth looking into.

Criticality score components:

  1. Severity - The insight severity measures the insight relative to the problem it is describing. For example: The N+1 issue severity is determined by the number of repeated queries whereas the Scaling issue severity is determined by the performance degradation slope. You can find a description of how each issue's criticality is measured on each issue's dedicated .

  2. Usage (shared environments) - The other component for calculating criticality is measuring how the insight is manifesting. Specifically, how many requests and user flows it is affecting. This is only relevant in non-local non-dev environments.

Insights that have a very high criticality score will be further highlighted in the UI and contain the may affect production message.

Finally, when using the Issues tab you can choose to sort by issue criticality to home in on the most critical issues.

page