# Monitoring and Managing Repositories Once your code repositories and ticketing systems are connected under **Change Management Systems**, Sprinto automatically begins monitoring them for compliance-related checks — such as peer reviews, branch protection, and code classification. Each connected system (for example, GitHub, GitLab, or Azure DevOps) includes multiple tabs that let you view repository activity, integration branches, and peer review status. From here, you can view failing checks, classify repositories, assign owners, upload evidence, and manage compliance status across your codebase. *** ### **Accessing the Repository Dashboard** 1. **Navigate to Change Management Systems** * Log in to the **Sprinto dashboard**. * Go to **Data Library → Change Management**. * On the **Change Management Systems** tab, click the connected provider (for example, *Azure DevOps* or *GitHubApp*). 2. **View Provider Summary** * The provider overview shows pending tasks and overall compliance status. * Example: *4 pending tasks (3 failing, 1 passing)*.
*** ### **Tabs in the Repository Dashboard** Each connected provider includes four tabs that provide detailed insights:
TabDescription
SummaryDisplays pending tasks, number of failing checks, and overall compliance health.
Repos MonitoredLists all repositories being tracked, along with their classification, owner, and check status.
Integration BranchesShows monitored branches and their associated checks (for example, merging or peer review rules).
Peer ReviewsDisplays repositories where peer review requirements are being enforced or need attention.
*** ### **Viewing and Fixing Checks** 1. In the **Repos Monitored** tab, each repository displays: * Repo name * Account * Repo owner * Classification (*Production* or *Not Production*) * Current check status (*Passing* or *Failing*)
2. Click on any repository or failing check to open the **Check Details** drawer.
2. Review the issue under **Check Details** (for example, “Code repo should be classified”). 3. Use the **three-dot menu** to perform actions such as: * **Upload evidence** for unresolved checks. * **Mark as special case** for justified exceptions. * **Manage assignment or escalation** (for example, reassign to another owner). * **Report issue** if the check result appears inaccurate.
*** ### **Classifying Repositories** 1. In the **Repos Monitored** tab, click on a repository that is *Unclassified*. 2. Select **Production Repo** or **Not Production Repo**. 3. If choosing **Production**, select a **CI branch** to monitor. 4. Click **Save** to confirm. * Sprinto uses this classification to determine the compliance checks applied to that repository.
*** ### **Assigning or Updating Repo Owners** 1. Open a repository and select the **Change** option next to the repo owner field.
2. From the list of available users, select the new owner. 3. Click **Update** to confirm. * All existing and future checks for the repository will now be assigned to the new owner.
*** ### **Managing Branch-Level Checks** 1. Navigate to the **Integration Branches** tab. 2. Click a branch (for example, `main` or `develop`) to view its associated checks.
3. Review failing checks such as: * “Branch protection rules should be enforced for admins” * “Merging of code changes should require passing status checks” * “Peer review should be enforced for code changes” 4. To fix, follow the **How to Fix** steps shown in the drawer. You can also upload evidence or mark as a special case if applicable.
*** ### **Managing Organisations Under a Provider** 1. In the provider view, click **Manage** next to the provider name.
2. Review: * **Organisations monitored** for code changes. * **Organisations not monitored** for code changes. 3. Click **Manage** next to each organisation to start or stop tracking. * To stop tracking, click **Stop Tracking** in the organisation details pane.
*** ### **Best Practices** * Regularly review the **Summary** tab to identify failing checks early. * Ensure all repositories are **classified** and **assigned to an owner**. * Use **evidence uploads** to maintain audit readiness for change-related controls. * Stop tracking inactive or deprecated repositories to avoid unnecessary alerts.