Mention members and teams in incident notes
Release Date: July 20, 2026
![]()
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
@nameor 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 source status: 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.
- 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.















