> For the complete documentation index, see [llms.txt](https://docs.opsmx.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opsmx.com/delivery-intelligence-and-orchestration/delivery-intelligence-and-orchestration-overview/insights.md). # Insights The Insights page provides a real-time, time-scoped view of your organisation's software supply-chain scanning activity. Security and engineering leaders can monitor scan coverage, track CI/CD event ingestion, and measure automated remediation progress — all from a single, unified dashboard plotted as trends over time. Use Insights to maintain continuous visibility into the health of your scanning pipeline, validate that all integrations are actively delivering telemetry, and proactively identify gaps in scanning coverage or remediation effectiveness before they become security liabilities. ### To Access Insights Navigate to Insights in the left navigation panel. The page loads with data for the last 7 days by default. ### Filtering by Date Range All charts on the Insights page are scoped to a selected date range, giving you the flexibility to analyze activity over different time windows. At the top-right of the page, is the **Show Data for** date-range picker. 1. Click the date field to open the calendar. 2. Choose a preset range **Last 7 days, Yesterday, Today, Last 30 days, This Month, Last Month, All** or select a **Custom start and end date**. 3. All charts update simultaneously to reflect the selected range.

### Charts and Metrics The Insights page is organised into a grid of chart panels, each focused on a specific metric category. All time-series charts plot values on the Y-axis against time (UTC) on the X-axis. #### Charts and Metrics The Insights page is organised into a grid of chart panels, each focused on a specific metric category. All time-series charts plot values on the Y-axis against time (UTC) on the X-axis. ### **Scan Metrics** These panels give you a high-level view of the overall health of your scanning pipeline — how many scans are active, how many have completed successfully, and how many have failed. * **Active Scans Count** — The number of scans currently in progress within the selected range. A sustained high value may indicate a backlog or resource constraint in the scanning infrastructure. * **Scans Completed Count** — The total number of scans that finished successfully. Use this to understand scan throughput and identify drops that could indicate scheduling or connectivity issues. * **Scans Failed Count** — The number of scans that did not complete successfully. Spikes on this chart should prompt investigation into scanner configuration, credentials, or network connectivity.

### **Repository Metrics** These panels focus on source code repository coverage — how many repositories are being actively scanned, how many scans have completed, and how many repositories are newly discovered within the selected period. * **Active Count** — The number of source code repositories currently undergoing a scan. A flat-zero value over time may indicate that scheduled scans are not triggering as expected. * **Completed Count** — Repositories for which a scan has successfully completed during the selected period. Tracking this over time shows whether your scanning coverage is growing or stagnating. * **Failed Count** — Repositories where the scan did not complete. Persistent failures against the same repositories often point to permission issues or unsupported repository types. * **New Repositories Discovered** — The count of repositories detected for the first time during the selected range. A rising trend here indicates that your organization's codebase footprint is growing and may require additional scanning capacity to maintain coverage. ### **CI/CD Metrics** * **CI/Build Events Received Count** — The number of CI and build pipeline events that SSD received during the selected period. This confirms that your build system integrations — such as Jenkins, GitHub Actions, and GitLab CI — are actively sending event data to SSD. A drop to zero typically means a webhook or integration has become disconnected and requires immediate attention.

### **Remediation Metrics** #### **SAST Agent – Remediation Events** This panel uses a horizontal stacked bar chart to show the lifecycle status of automated remediation actions triggered by the SAST agent. Each bar represents a group of remediation requests and is broken down into the following statuses: * **Remediation Requested** *(Teal)* — A fix has been requested but not yet started. * **Remediation Started** *(Orange)* — The agent is actively attempting the fix. * **Remediation Completed** *(Green)* — The fix was applied successfully. * **Remediation Failed** *(Red)* — The automated fix attempt was unsuccessful. * **PR Created** *(Blue)* — A pull request containing the fix was opened in the repository. * **PR Creation Failed** *(Dark Red)* — The agent could not open a pull request. A healthy remediation pipeline will show a majority of events in **Completed** or **PR Created** status. A growing **Failed** or **PR Creation Failed** segment may indicate repository permission issues or merge conflicts that are blocking the agent from completing remediation. #### **CSPM Agent – Remediation Events** This panel uses a horizontal stacked bar chart to show the lifecycle status of automated remediation actions triggered by the CSPM (Cloud Security Posture Management) Agent. The CSPM Agent detects misconfigurations and policy violations in cloud infrastructure and initiates fixes automatically. Each bar represents a group of remediation requests and breaks down into the following statuses: * **Remediation Requested** *(Teal)* — A cloud misconfiguration fix has been requested but not yet started. * **Remediation Started** *(Orange)* — The CSPM Agent is actively attempting the fix. * **Remediation Completed** *(Green)* — The misconfiguration was successfully resolved. * **Remediation Failed** *(Red)* — The automated fix attempt was unsuccessful. * **PR Created** *(Blue)* — A pull request containing the infrastructure fix was opened. * **PR Creation Failed** *(Dark Red)* — The agent could not open a pull request for the fix. A healthy CSPM remediation pipeline will show a majority of events in **Completed** or **PR Created** status. A growing **Failed** or **PR Creation Failed** segment may indicate cloud provider permission issues, policy conflicts, or unsupported resource types that require manual intervention. #### **Binary Agent – Remediation Events** This panel uses a horizontal stacked bar chart to show the lifecycle status of automated remediation actions triggered by the Binary Agent. The Binary Agent scans compiled artefacts, container images, and binary packages for vulnerabilities and initiates fixes — typically by upgrading affected dependency versions or rebuilding images with patched base layers. Each bar represents a group of remediation requests and breaks down into the following statuses: * **Remediation Requested** *(Teal)* — A binary vulnerability fix has been requested but not yet started. * **Remediation Started** *(Orange)* — The Binary Agent is actively attempting the fix. * **Remediation Completed** *(Green)* — The vulnerability was successfully patched. * **Remediation Failed** *(Red)* — The automated fix attempt was unsuccessful. * **PR Created** *(Blue)* — A pull request with the patched dependency or rebuilt image reference was opened. * **PR Creation Failed** *(Dark Red)* — The agent could not open a pull request for the fix. A healthy Binary Agent remediation pipeline will show a majority of events in **Completed** or **PR Created** status. A growing **Failed** segment often indicates that no patched version of a dependency exists yet, the binary format is unsupported, or the target repository has branch protection rules that are blocking automated changes.