Sprkl offers a dashboard that integrates the code execution analysis results. The dashboard comprises various sections that display relevant information regarding your recent code changes and their effects.

The dashboard contains multiple sections. Each section has its unique structure. A commonly used record in every section is the code block reference.



The errors section aggregates errors found during the application execution.

There are two types of errors:

  1. Errors were thrown through the code changes that were analyzed.

  2. Errors that were found on infrastructure/library code execution (spans).

An error thrown through code changes will contain the code block reference alongside the error message display.


The coverage is not regular code coverage, as we know. This is a git-analysis-based coverage, meaning the coverage relates to blocks that were analyzed and marked as relevant (checkout Analysis). It's a critical metric that can tell you much about your testing in relation to the code changes you've made - Did I test all the code under the commit or pull request I'm pushing?

The coverage is split into two categories: covered and uncovered.

The covered subsection contains records of executed code (found related spans). Each record represents a code change. The uncovered subsection contains code you have that was scanned, but no runtime execution was detected (no relatable spans).


Insights are not necessarily errors but opportunities for you to identify specific areas in your recent code change that can be improved. It helps you ensure that your code performs better and prevents particular issues from being pushed to production.

A couple of insights provide are:

  • Circular call: We found an HTTP request being made where the server and the client are of the same host. Meaning the request was made to a service by itself. This might be ok, but sometimes, it is better to call an internal function or method instead of performing a network-involved request.

  • Async work added: We found a non-blocking operation that takes a long time and is related to the code marked in the analysis.

  • API performance impacted: We found that the marked code change execution takes a large chunk of time as part of an API request. This indicates that you have added significant work to your API.


Interactions show the ripple effect of your recent code change on the different system components. You can see details on HTTP requests, including the appropriate methods and database queries, including collections and procedures, queues, and other components. You can also see the details of your Jest tests execution, including tests that passed through the recent code change and that didn't, mocks, and assertions.

We support the following components:

  • HTTP

  • GraphQL

  • Databases: Any database instrumented with OpenTelemetry. A detailed view is provided for MongoDB, SQL, and Redis databases.

Security (New!)

Dependencies vulnerabilities

The vulnerabilities subsection in the security section aggregates the REACHED vulnerabilities (CVEs) found during execution. Sprkl will report to you actual packages loaded during runtime and called, which contain security vulnerabilities.

Click here to learn more

Source code risks

The source code risks subsection in the security section aggregates risks that were scanned by a static analysis tool (i.e. - Semgrep, Snyk) and were included in the linked SARIF file. Sprkl will report to you on risks that were scanned by the static analysis tool and risks that were both scanned and executed during runtime.

The risks are divided into two categories: scanned and triggered.

The scanned category includes risks that were detected in the code but have not yet been triggered during runtime (no relatable spans). The triggered category includes risks that were executed during runtime (found related spans). For every triggered risk, there is a list of its triggers. A trigger is either an API call or an executed code block that caused the risk execution.

Due to limitations in the instrumentation process, some of the scanned risks in the project may not be instrumented. Those risks will be shown under the "Scanned but not instrumented" tab in the scanned subsection.

Click here to learn more






Last updated