Semgrep had 67 outages in the last 2 years totaling 98h 18m of downtime — averaging 2.8 incidents per month.
There were 67 Semgrep outages since September 12, 2025 totaling 98h 18m of downtime. Each is summarised below — incident details, duration, and resolution information.
We are investigating an increase in traffic causing platform wide issues. The UI, scanning, and API may be affected.
We believe we have recovered, we are monitoring for additional impact.
This incident has been resolved.
An incomplete patch release of Semgrep 1.176.1 has left installations of this version using PyPI unable to use the Pro Engine. We recommend explicitly installing version 1.175.1 or 1.176.0 as we work to resolve this issue.
This issue has been resolved. The Pro Engine can be installed and used normally after installing Semgrep 1.176.1 via PyPI.
We are currently investigating this issue.
AWS STS outage in us-west-2 is affecting our system. We are investigating mitigations.
Early signs of recovery for all Semgrep products. We are actively monitoring AWS updates on the regional, multi-service outage.
Metrics show full recovery of all Semgrep products. Our engineering team will continue monitoring until the final update from AWS.
A small number (<1%) of supply chain scans that dynamically resolve dependencies for gradle and maven projects have been failing since August 28, due to rate limiting applied by a public package registry. Affected projects may show incomplete or missing Supply Chain findings. We are rolling out a caching mirror to reduce the impact of these rate limits. Subsequent scheduled scans should resolve any impacted findings. No further action from customers is required at this time.
Under one percent of supply chain scans that dynamically resolve dependencies for gradle and maven projects have been failing, due to rate limiting applied by a third-party package registry. Affected projects may show incomplete or missing Supply Chain findings. We are rolling out a caching mirror to reduce the impact of these rate limits. Subsequent scheduled scans should resolve any impacted findings. No further action from customers is required at this time
The third party registry's rate limits have been lifted, and impact to scans appears mitigated.
Dynamic maven & gradle scans are now operating as normal.
A bad release is causing widespread failures in the Semgrep AppSec Platform.
The release has been rolled back and the platform is now stable.
This issue has been fully resolved with a successful release.
Semgrep experienced an outage affecting login, the API, and scans from 2026-08-13 23:43 UTC to 23:52 UTC. The incident has been resolved.
We are currently investigating this issue.
We've identified the root cause of the issue and are currently working on a fix.
We have rolled out a fix, and scans are now working as expected. We are closely monitoring to ensure continued stability.
This incident has been resolved.
We are currently investigating this issue.
We have identified the issue and are actively working on a fix.
A fix has been deployed. We will continue to monitor our systems to ensure that the issue has been resolved.
This incident has been resolved.
Processing of findings data has been delayed since approximately 03:20 UTC and is currently lagging approximately 3 hours behind realtime. The underlying cause has been addressed and we are monitoring to ensure the backlog is processed.
Backfill is continuing and lag has reduced to approximately 1 hour behind realtime. We continue to monitor to ensure progress.
This issue has been resolved, and findings data is now displaying normally.
We're aware of an issue where customers with custom SSO configs are unable to login to Semgrep and are seeing a 504 Gateway Timeout error. The issue is under investigation
This incident has been resolved by the third party vendor
We've observed that when trying to add a new memory, the Memories page crashes, and we are investigating the issue.
We've identified the root cause and observed that both creating and editing memories is affected. We are working on a fix for the issue.
The fix has been released and this issue is resolved.
We have observed widespread scan failures relating to a bad release of AI skills rules. We are working to fix the issue. To prevent the issue in the meantime, you can disable the "skills.behavioral.skill-destructive-commands.skill-destructive-commands" rule in your Semgrep policies.
We have removed the problem rule ("skills.behavioral.skill-destructive-commands.skill-destructive-commands") and we are seeing scan behavior recover. We are continuing to monitor for full recovery.
This issue has been resolved. Scans are now running normally.
We are currently investigating this issue.
The issue has been identified and a fix is being implemented.
We are currently investigating this issue.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
We are currently investigating an issue causing degraded scan performance in CI and Semgrep Managed Scans, and are actively working to resolve it.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further issues.
This incident has been resolved.
We are currently observing login issues using GitHub auth. Our team has identified the issue and is currently working on a fix. SSO logins are working as expected and are not impacted.
We have rolled out a fix, and logins are now working as expected. We are closely monitoring to ensure continued stability.
This incident has been resolved.
This incident has been resolved.
We are currently investigating an issue where full project scans in Managed Scans are being associated with HEAD rather than the name of the default branch. This issue started around 16:00 UTC on May 19 and may result in unexpected new findings notifications, and some findings not being closed as expected.
We have identified the issue and are working on a resolution.
We have deployed the fix and are monitoring.
This incident has been resolved.
We are investigating delays scheduling SMS scans. This issue began at approximately 18:30 UTC today.
We are continuing to investigate the issue. We will post updates when further information is available.
We have identified a likely cause of this incident. We are currently rolling out a change to address it.
Since the beginning of the incident, a portion of SMS scans have failed to execute. We have deployed a change to the system. We are seeing scheduling queues begin to recover, and we're continuing to monitor the situation.
The scan success rate is recovering. We are continuing to monitor the system.
This incident has been resolved. We are continuing to monitor the system.
We are currently investigating a performance issue with the Semgrep AppSec Platform that started around 16:00 UTC (9:00 AM Pacific).
The performance of the platform is beginning to return to baseline. We are continuing to investigate what caused the issue.
We are continuing to investigate the issue. While overall performance has remained relatively stable since 10:30 Pacific, some reporting metrics and issue details may lag behind realtime.
Latency and errors have increased in the last hour. We are continuing to investigate the performance issues and apologize for the impact.
We have applied mitigations but are continuing to investigate the root cause of the issue. Platform performance may still lag at times and some reporting and issue status data may be stale.
This issue has been resolved. We determined that the performance degradation had multiple contributing causes and will be working to address those issues.
Between 21:48 - 22:00 UTC some managed scans experienced additional latency. The root cause has been resolved.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
From 14:35 to 14:52 UTC, Semgrep scans did not start successfully. We have mitigated the issue and scans are now starting normally.
Starting around 16:00 UTC, some diff-aware Managed Scans for GitHub.com projects failed due to inability to fetch information about relevant branches, coinciding with a degradation in GitHub availability. The failure rate returned to normal just after 17:00 UTC and the system is now stable.
We have identified a problem in the service that generates the configuration for new scans. This incident began at approximately 17:30 UTC, and it affects both Managed Scans and CI scans. We have taken action and are actively monitoring the system. If you have a scan that is pending, you can push a new commit to cause the scan to retry.
This incident has been resolved.
Some users are unable to log in, and some managed scans are failing to start. We're investigating both.
We've identified the cause of the backend issues. Some traffic has resumed but services are still degraded, and we're continuing to remediate.
The problem is resolved and scans and logins are now processing normally.
Since 22:00 UTC, some fail-open processes for unfinished Managed Scans may have been delayed up to 40 minutes. We are investigating the issue.
We have implemented a change to allow faster processing of fail-open requests, and the delay has reduced to under 5 minutes. We are monitoring to ensure the system remains stable.
This issue has been resolved. Fail-open processes for unfinished Managed Scans continue to run normally.