GitOps Under Fire: Resilience Lessons from GitProtect’s Mid-Year 2025 Incident Report
GitOps is at the heart of today’s cloud-native delivery pipelines — but what happens when the very platforms it relies on begin to falter?
That’s the uncomfortable question raised by GitProtect.io’s DevOps Threats Unwrapped: Mid-Year Report 2025, which chronicles 330 recorded outages and degradations across the most critical DevOps platforms: GitHub, GitLab, Jira, Azure DevOps and Bitbucket.
These are not isolated events. The report captures a trend that’s as much about operational fragility as it is about evolving threat vectors. The implications for the Kubernetes ecosystem, GitOps automation, platform reliability and continuous deployment are significant — and growing.
GitHub: The GitOps Linchpin Shows Stress Fractures
GitHub is more than just a repo — it’s the de facto source of truth for most GitOps pipelines. In H1 2025:
- 109 incidents were recorded (up from 69 in H1 2024)
- 17 major events led to 100+ hours of disruption
- 330 hours of downtime occurred in April alone
For cloud-native teams using tools like Argo CD, Flux, or custom Kubernetes controllers, these disruptions translate to more than just delayed CI/CD—they disrupt declarative infrastructure synchronization, rollout velocity and even incident response workflows.
May recorded the highest frequency of incidents, but April delivered the longest cumulative pain. This introduces a new category of concern: GitOps availability dependencies.
Azure DevOps: CI/CD Pipelines Hit Repeatedly
Microsoft’s Azure DevOps suffered 74 incidents, with pipelines — the core engine for GitOps-triggered builds — being the most unstable service (31 events).
The standout event: A 159-hour performance degradation in January that crippled build and deploy workflows across the globe.
Europe accounted for 34% of all incidents, with localized impact analysis suggesting regional performance instability. If your Kubernetes clusters are running in Azure and your pipeline triggers reside in Azure DevOps, you’re in a double jeopardy zone.
GitLab: More Than Just Downtime — A Security Wakeup Call
GitLab’s 59 incidents in H1 2025 amounted to 1,346 hours of degradation, but the more jarring event was the Europcar Mobility Group data breach.
Threat actors stole:
- Android and iOS source code
- Personally identifiable information for ~200,000 customers
For cloud-native teams using GitLab as both a CI engine and artifact store, this breach represents the convergence of availability and security risks in the DevOps pipeline.
Jira: 2,390 Hours of Disruption — And Ransomware
Jira isn’t just for ticketing — it’s the feedback loop that connects operations with SREs, platform engineers, and developer teams. When it goes down, visibility suffers.
- 66 incidents
- 100 days of downtime
- Targets of ransomware attacks by the HellCat group included Jaguar Land Rover, Telefónica, and others
This raises new questions for platform teams: How do we track change management, incident resolution, or team SLAs when the backbone of our observability stack (Jira) is unreliable?
From Perimeter Defense to GitOps Resilience
As Greg Bak of GitProtect puts it:
“Traditional perimeter security is no longer sufficient… Anticipating failures before they happen, paired with self-healing infrastructure and recovery strategies that go beyond just technology, will redefine how organizations safeguard uptime, data integrity, and business continuity.”
In the cloud-native space, that means:
- Redundant Git remotes and failover strategies
- Pull-based CD fallback in GitOps
- Snapshotting and backup at the repository level
- Zero-trust integration between GitOps components
It’s not just about backing up your Jira boards anymore. It’s about engineering for failure across every layer of your delivery platform — from YAML to UI.
Conclusion: Resilience Engineering Must Include GitOps
As GitOps matures from an early adopter pattern to an enterprise standard, its dependency on external platforms becomes a critical risk vector. GitProtect’s report is more than a warning — it’s a call to action for platform engineering and SRE teams to expand their definition of reliability to include supply chain stability, platform DR and Git-level observability.
👉 Read the full report.
