For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

AI governance is an ongoing game of catch-up for enterprises. Model updates and iterations are rolling out at a rapid clip, often making governance frameworks obsolete before they’re battle-tested.

To evolve beyond this paradigm, OpenAI is introducing Active sessions. This new ChatGPT security feature allows users to review and log out of one or more sessions through a simple interface. The feature is now available across all ChatGPT accounts and workspace types, including personal and managed workspaces. Experts call it an important development for the model provider, which currently has 1 billion monthly active users.

Previously, organizations often had limited visibility into where users were logged in, and simply relied on password resets or broad account actions to force re-authentication, noted Ensar Seker, CISO at SOCRadar. “Granular session control is a more efficient and less disruptive approach. From a governance perspective, session transparency improves accountability and supports investigations,” he explained.

A holistic view across session activity

Active sessions allows admins to see known browser and app sessions across ChatGPT, Codex, and API Platform. Specifically, they are able to view device and browser information, approximate location, sign-in date and time, whether a device is trusted, and whether the session is current.

To access the feature, users can go to ‘Settings’ > ‘Security’ > ‘Active sessions.’ They can then log out of specific sessions and remove devices from trusted services. They also have the ability to log out of all sessions (thus ending sessions across devices), however, this action can take up to 30 minutes to complete.

However, OpenAI emphasizes that session details may be “approximate or incomplete,” and that the feature has limits. It does not show or manage connected apps or third-party app sessions, sign-ins through third-party services, Codex CLI sessions, or recently signed-out sessions.

Further, Active sessions cannot be used with accounts linked to an enterprise’s single sign-on (SSO), including security assertion markup language (SAML) and OpenID Connect (OIDC).

Better late than never

While Active sessions is an important security and governance development, experts note that the feature is basic, and was a long time coming.

“The reality of OpenAI offering the ability to end active sessions on ChatGPT by administrators is that it’s something that exists in lots of platforms,” said David Shipley of Beauceron Security. “They should’ve had it sooner, but better late than never.”

From a security standpoint, he noted, OpenAI could do a better job policing ChatGPT to prevent it being used by threat actors to host malware, which is the latest threat to enterprises.

SOCRadar’s Seker also pointed out that this type of visibility and oversight is something that enterprises have expected from SaaS platforms for years. “It allows administrators and users to quickly identify unauthorized access, terminate stale sessions, and reduce the risk of account compromise persisting undetected.”

Iterative upgrades disrupt governance

Last week, OpenAI updated GPT-5.5 Instant in both the ChatGPT app and API to “improve response style and quality,” the company said. It had rolled out GPT-5.5 Instant earlier in May as a successor to GPT‑5.3 Instant, calling it “generally smarter” and prone to fewer hallucinations.

According to OpenAI, the update makes GPT-5.5 Instant “easier to read, more natural in everyday conversations, and better paced in practical help tasks, with fewer overly long or bullet-heavy responses.”

But even with tools like Active sessions, enterprises continue to struggle with governance amidst seemingly continuous iterative model updates. It’s simply not sustainable, said Beauceron’s Shipley: “How do you build an appropriate testing plan with a nondeterministic system?”

SOCRadar’s Seker pointed out that many organizations perform security, compliance, and business validation testing before approving a model for production use. But, “when model behavior changes under the same version family, previously documented assumptions may no longer fully reflect actual performance,” he noted.

“The biggest governance challenge in AI is not model adoption, it’s model change,” Seker said. “Most organizations can evaluate a model once. Far fewer are prepared to continuously evaluate how that model evolves over time.”

This particularly creates challenges for regulated industries where auditability, repeatability, and change management are critical, he said. Even beneficial improvements can introduce governance concerns if organizations are not clearly informed about what changed and when.

Valence Howden, advisory fellow at Info-Tech Research Group, noted that organizations often can’t assess the implications of model iterations against their boundaries, and, worse, are often unaware of them.

While the biggest enterprise challenge was initially tied to which AI model was being used, what that model did, and who owned it, iterative updates can muddy those waters and increase reliance on third party practices and tools that organizations often don’t have the resources for, he noted. 

“Without the ability to opt out [of an update] before it’s incorporated, [enterprises] are basically red-teaming the updates with their clients,” said Howden.

The ongoing game

Security teams today are pushed to their limits because they are expected to manage rapidly evolving models, new features, and changing behaviors, while maintaining compliance, risk management, and business continuity, said SOCRadar’s Seker.

“Governance is difficult because organizations are no longer evaluating a static product,” he said. Rather, they are managing a “continuously evolving service” where capabilities, integrations, and user behaviors can change far faster than can traditional security review cycles.

Info-Tech’s Howden agreed, saying that enterprises’ existing governance practices, especially accountability, are poor, as are their risk practices.

“It’s hard to suddenly become good at things they’re already poor at doing,” he said. “They are also incentivized for speed and innovation, so they ignore governance as a constraint, or don’t want to do it at all.”

How enterprises should respond

Seker advised that, ultimately, organizations should treat AI models as living systems rather than fixed software releases.

Security and governance programs should include continuous validation, monitoring, and periodic re-assessment instead of sole reliance on one-time approval processes, he said. Enterprises should also establish clear vendor change management expectations, including requiring transparency around model updates, behavioral changes, and potential impacts to existing workflows.

“Effective AI governance increasingly depends on visibility into change, not just visibility into risk,” Seker said.