Skip to main content

2 posts tagged with "github"

View All Tags

Track your GitHub check runs from the dashboard

calendar icon   Release Date: July 28, 2026

GitHub check runs dashboard

GitHub check runs now have a dedicated page in the GitGuardian dashboard. Until now, check run results lived only in the GitHub UI, making it hard to answer questions like "did this pull request get scanned?" or "why did this check fail?" without digging through GitHub. The new GitHub check runs page, available in the Perimeter section, brings every check run into one place.

What does this mean for you?

  • Full visibility into every scan: Browse all your check runs with their status (Successful, Failed, Skipped, and more), repository, commit SHA, associated pull request, and timing.
  • Find what you need fast: Filter by repository, status, or date, and search across your check runs, even on workspaces with hundreds of thousands of runs.
  • Key metrics at a glance: A KPI strip at the top of the page summarizes your check run activity so you can spot failures and trends immediately.
  • Recover without leaving the dashboard: Re-run a check directly from the list, or skip it when appropriate, without switching back to GitHub.
  • Jump to linked incidents: When a check run detects secrets, navigate straight to the related incidents to start remediation.

Why is this important?

Check runs are your first line of defense against secrets entering your repositories. When they fail or get stuck, pull requests are blocked and developers lose time. This page gives security teams and admins a single place to audit scan coverage, troubleshoot failed runs, and unblock developers quickly.

Get started today!

Open the Perimeter section of your GitGuardian dashboard and select the GitHub check runs tab. Learn more in our documentation.

Enhancements​

  • Public perimeter: Fine-grained GitHub personal access tokens can now be used to monitor private member of a GitHub organization, in addition to classic tokens.
  • Integration source pages: The Display as Tree view was removed from integration source pages, and only the Display as List view was kept. The tree view could cause frozen or lagging pages on workspaces with large perimeters, while the list view covers the same use case with better performance.
  • Sources health management for Bitbucket Cloud, Bitbucket Data Center, GitLab, and Azure DevOps: Extending the source health coverage from previous releases, GitGuardian now pauses real-time ingestion and historical scans on unreachable Bitbucket, GitLab, and Azure DevOps sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to the other VCS in upcoming releases. See the integration guides for Bitbucket Cloud, Bitbucket Data Center, GitLab, and Azure DevOps.

Fixes​

  • Email & MFA: Fixed an issue where multi-factor authentication emails were not delivered to users who had been globally unsubscribed in the email delivery system.
  • Source monitoring: Fixed a performance issue where every push event triggered a full repository clone instead of reusing locally cached data.
  • Slack integration: Fixed an issue where the Slack integration monitored channels that were not manually added, even when auto-monitor was disabled.
  • Incident notes: Fixed an issue where user mentions in the incident feedback popover displayed a raw identifier instead of the member's display name.

Mention members and teams in incident notes

calendar icon   Release Date: July 20, 2026

Mention members and teams in incident notes

You can now mention members and teams directly in incident notes and feedback. Type @, pick a member or team from the searchable list, and they are notified, so the right people see the incident without leaving the note.

What does this mean for you?

  • Loop in the right people instantly: Mention a member with @name or a whole team with @team-name. The mentioned member, or every member of a mentioned team, receives an email linking straight to the incident.
  • Faster collaboration on incidents: Keep the conversation where the work happens, with no switching to Slack or email to ask a teammate to take a look.
  • Works across the platform: Mentions are supported on both Internal Monitoring and Public Monitoring incidents.

Why is this important?

Remediation is a team effort. When an incident needs a specific owner or a team's attention, mentions cut the back-and-forth and shorten response time, while respecting existing permissions.

Get started today!

Open any incident, add a note or feedback, and type @. Manage your mention emails from your notification settings under Workspace.

Enhancements​

  • Sources health management for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive: Extending the source health coverage from previous releases, GitGuardian now pauses real-time ingestion and historical scans on unreachable sources of these types, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the integration guides for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive.
  • Perimeter:
    • sources now show a status (Monitored, Unmonitored, Unreachable, Archived, or Deleted) that you can filter on from the perimeter page and the incident list, and save as a view (e.g. to set aside incidents from archived or deleted sources). Note: a valid secret in an archived or deleted source is not necessarily less risky. See Manage your monitored perimeter.
    • You can now choose which columns are displayed in the perimeter table, so you can surface the source attributes that matter most to you and tailor the view to your workflow.
    • On top of setting criticality and launching scans, you can now bulk Monitor, Unmonitor, and Assign team on selected sources directly from the perimeter page. Selecting more than 30 sources shows a confirmation popup before the action runs. Note that Assign team only adds monitored sources to a team, and unmonitoring a source removes it from all of its teams, so those teams' members lose access to that source's incidents. Only managers can monitor, unmonitor, or assign teams. See Bulk actions on perimeter sources.
    • Historical scans now have their own tab on the perimeter page, so you can track past and in-progress scans and their status in one place. See Historical scanning.
  • GitHub check runs, scan very large pull requests (Business plan): Previously, pull requests above the size limit (200 commits, 60,000 files, or 300,000 lines changed) were skipped to protect your GitHub API rate limit. On the Business plan, GitGuardian now scans these oversized pull requests by cloning the repository branch instead of calling the GitHub API commit by commit. This reuses the clone-based approach already used for historical scans, avoiding rate-limit consumption while still scanning the full pull request. On other plans, oversized pull requests are still skipped. Learn more.
  • Custom Sources (BYOS), scan with validated detectors only: Custom Source installs can now enable a "use only detectors with validators" option. When it is on, a source-linked scan keeps only secrets whose detector supports validity checks and drops the rest before the validity check runs, cutting noise from matches that can never be verified. The option is opt-in per install. Learn more.
  • JFrog Container Registries: Backfilled author information for existing JFrog container registry occurrences.

Fixes​

  • Audit Logs: Changes to monitoring settings (such as toggling automatic monitoring on or off) are now logged in the audit trail.
  • Custom Webhooks: Fixed an issue where Discord webhook notifications were not triggering on incident alerts.
  • Jira Cloud Integration: Fixed an issue where Jira Cloud sources were not performing recurrent scans as expected.
  • Bitbucket DC Integration: Fixed an issue where some Bitbucket Data Center sources stopped being monitored after infrastructure maintenance.
  • GitLab Integration: Fixed an issue where updating the integration token failed with an "invalid token" error.

Something we didn’t cover?

See our Roadmap

Subscribe on GitHub

Submit a request

API status