Skip to main content

Don't Let an IT Service Disruption Lead to Catastrophic Downtime

Krishna Dunthoori
Apty

Over the years, we've seen several high-profile examples of how even the slightest human error can induce devastating bouts of downtime. One infamous example came several years ago, when Amazon's S3 service was knocked offline, obliterating service to social media platforms, web publishers, and other leading websites. The cause? A simple typo — an authorized employee intended to take a small number of servers offline to fix a problem with the billing system, but accidentally entered a command incorrectly and removed a large number of servers instead.

Within several hours, Amazon's S3 service was back online, but the incident had lasting ramifications. Numerous popular apps and websites were impacted, and the estimated cost to S&P 500 companies was $150 million, while US financial services companies lost an estimated $160 million in revenue.

Even for the average organization (i.e., one not of Amazon's size), the cost of application downtime stands at a staggering $5,600 per minute. Moreover, outages are continuing to increase, as more people within an organization are empowered to make changes to IT services. In fact, a large majority of all incidents reported to an IT service desk are caused by change.

IT Service Management (ITSM) solutions are widely available to help solve this problem, with incident management as one of its main pillars. Incident management enables the rapid identification, notification, and resolution of critical application outages, and provides a clear, documented process to follow if and when things go wrong. The reported percentage of IT projects that result in failure depends on the article or survey you read, but most put the number at 55 - 75 percent. So why do so many ITSM implementations fail?

Like other software implementations, ITSM often suffers from a lack of user adoption. This is because people, by nature, are resistant to change. Sometimes, organizations and their training teams erroneously believe they can communicate once or twice about a new software implementation, deliver a round of training, and sit back and expect to realize software value. However, in prioritizing go-live, many training teams fail to properly support user adoption in the ensuing days and months, and adoption never reaches meaningful levels.

But in an incident response context, something else seems to be going on. Any strong emotion that temporarily impairs our thinking — anxiety, fear, or anger, for example — can result in a "brain freeze," or a temporary decline in cognitive functioning. So when an incident occurs, the ensuing panic among employees who are likely unfamiliar with the ITSM solution anyway, makes the situation that much more grim.

So how can organizations and training teams harness the full potential of ITSM solutions to maximize application uptime?

There are several areas to focus on, including:

Seamless onboarding and increasing user adoption - Organizations and their training teams need to simplify the ITSM onboarding process by providing real-time, in-app, context-driven guidance. This reduces the learning curve and eliminates the fear of embracing the new technology, while providing the right support at the right time.

Supporting change processes - Given the pace and frequency of change, context-driven guidance also makes it easier for ITSM users to implement changes posing fewer risks and disruptions, ensuring that changes are carried out much more smoothly.

Reducing all-important mean-time-to-repair (MTTR) - Especially in times of strain, context-driven guidance can also help ITSM users swiftly find information and efficiently resolve those IT issues they don't necessarily encounter every day, by providing in-the-moment, step-by-step guidance. This leads to augmented user productivity and satisfaction while minimizing service disruptions.

The Amazon S3 example may seem like an egregious example of "breaking the internet." Yet it clearly highlights how the slightest change or error can induce disaster, as well as the fragility of modern infrastructures — realities impacting all organizations. Successfully implementing and training on ITSM, and specifically incident management as part of an ITSM approach, can be vital in avoiding expensive downtime when a disruption occurs. The key is to have ongoing training and guided risk management in place so there is little to no pause in response when the inevitable error or disruption happens. This is where solutions like digital adoption platforms (DAPs) come into play to streamline and solve IT disruption downtime challenges — ensuring seamless and efficient adoption of ITSM tools.

Krishna Dunthoori is Founder and CEO of Apty

Hot Topics

The Latest

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...

Today's modern systems are not what they once were. Organizations now rely on distributed systems, event-driven workflows, hybrid and multi-cloud environments and continuous delivery pipelines. While each adds flexibility, it also introduces new, often invisible failures. Development speed is no longer the primary bottleneck of innovation. Reliability is ...

Don't Let an IT Service Disruption Lead to Catastrophic Downtime

Krishna Dunthoori
Apty

Over the years, we've seen several high-profile examples of how even the slightest human error can induce devastating bouts of downtime. One infamous example came several years ago, when Amazon's S3 service was knocked offline, obliterating service to social media platforms, web publishers, and other leading websites. The cause? A simple typo — an authorized employee intended to take a small number of servers offline to fix a problem with the billing system, but accidentally entered a command incorrectly and removed a large number of servers instead.

Within several hours, Amazon's S3 service was back online, but the incident had lasting ramifications. Numerous popular apps and websites were impacted, and the estimated cost to S&P 500 companies was $150 million, while US financial services companies lost an estimated $160 million in revenue.

Even for the average organization (i.e., one not of Amazon's size), the cost of application downtime stands at a staggering $5,600 per minute. Moreover, outages are continuing to increase, as more people within an organization are empowered to make changes to IT services. In fact, a large majority of all incidents reported to an IT service desk are caused by change.

IT Service Management (ITSM) solutions are widely available to help solve this problem, with incident management as one of its main pillars. Incident management enables the rapid identification, notification, and resolution of critical application outages, and provides a clear, documented process to follow if and when things go wrong. The reported percentage of IT projects that result in failure depends on the article or survey you read, but most put the number at 55 - 75 percent. So why do so many ITSM implementations fail?

Like other software implementations, ITSM often suffers from a lack of user adoption. This is because people, by nature, are resistant to change. Sometimes, organizations and their training teams erroneously believe they can communicate once or twice about a new software implementation, deliver a round of training, and sit back and expect to realize software value. However, in prioritizing go-live, many training teams fail to properly support user adoption in the ensuing days and months, and adoption never reaches meaningful levels.

But in an incident response context, something else seems to be going on. Any strong emotion that temporarily impairs our thinking — anxiety, fear, or anger, for example — can result in a "brain freeze," or a temporary decline in cognitive functioning. So when an incident occurs, the ensuing panic among employees who are likely unfamiliar with the ITSM solution anyway, makes the situation that much more grim.

So how can organizations and training teams harness the full potential of ITSM solutions to maximize application uptime?

There are several areas to focus on, including:

Seamless onboarding and increasing user adoption - Organizations and their training teams need to simplify the ITSM onboarding process by providing real-time, in-app, context-driven guidance. This reduces the learning curve and eliminates the fear of embracing the new technology, while providing the right support at the right time.

Supporting change processes - Given the pace and frequency of change, context-driven guidance also makes it easier for ITSM users to implement changes posing fewer risks and disruptions, ensuring that changes are carried out much more smoothly.

Reducing all-important mean-time-to-repair (MTTR) - Especially in times of strain, context-driven guidance can also help ITSM users swiftly find information and efficiently resolve those IT issues they don't necessarily encounter every day, by providing in-the-moment, step-by-step guidance. This leads to augmented user productivity and satisfaction while minimizing service disruptions.

The Amazon S3 example may seem like an egregious example of "breaking the internet." Yet it clearly highlights how the slightest change or error can induce disaster, as well as the fragility of modern infrastructures — realities impacting all organizations. Successfully implementing and training on ITSM, and specifically incident management as part of an ITSM approach, can be vital in avoiding expensive downtime when a disruption occurs. The key is to have ongoing training and guided risk management in place so there is little to no pause in response when the inevitable error or disruption happens. This is where solutions like digital adoption platforms (DAPs) come into play to streamline and solve IT disruption downtime challenges — ensuring seamless and efficient adoption of ITSM tools.

Krishna Dunthoori is Founder and CEO of Apty

Hot Topics

The Latest

As AI adoption accelerates, operational complexity — not model intelligence — is becoming the primary barrier to reliable AI at scale, according to the State of AI Engineering 2026 from Datadog ... The report highlights a compounding complexity challenge as AI systems scale ... Around 5% of AI model requests fail in production, with nearly 60% of those failures caused by capacity limits ...

For years, production operations teams have treated alert fatigue as a quality-of-life problem: something that makes on-call rotations miserable but isn't considered a direct contributor to outages. That framing doesn't capture how these systems fail, and we now have data to show why. More importantly, it's now clear alert fatigue is a symptom of a deeper issue: production systems have outgrown the current operational approaches ...

I was on a customer call last fall when an enterprise architect said something I haven't been able to shake. Her team had just spent four months trying to swap one AI vendor for another. The original plan said three weeks. "We didn't switch vendors," she told me. "We rebuilt half our integrations and discovered what we'd actually been depending on." Most enterprise leaders don't expect that to be the experience ...

Ask any senior SRE or platform engineer what keeps them up at night, and the answer probably isn't the monitoring tool — it's the data feeding it. The proliferation of APM, observability, and AIOps platforms has created a telemetry sprawl problem that most teams manage reactively rather than architect proactively. Metrics are going to one platform. Traces routed somewhere else. Logs duplicated across multiple backends because nobody wants to be caught without them when something breaks. Every redundant stream costs money ...

80% of respondents agree that the IT role is shifting from operators to orchestrators, according to the 2026 IT Trends Report: The Human Side of Autonomous IT from SolarWinds ...

40% of organizations deploying AI will implement dedicated AI observability tools by 2028 to monitor model performance, bias and outputs, according to Gartner ...

Until AI-powered engineering tools have live visibility of how code behaves at runtime, they cannot be trusted to autonomously ensure reliable systems, according to the State of AI-Powered Engineering Report 2026 report from Lightrun. The report reveals that a major volume of manual work is required when AI-generated code is deployed: 43% of AI-generated code requires manual debugging in production, even after passing QA or staging tests. Furthermore, an average of three manual redeploy cycles are required to verify a single AI-suggested code fix in production ...

Many organizations describe AI as strategic, but they do not manage it strategically. When AI plans are disconnected from strategy, detached from organizational learning, and protected from serious assumptions testing, the problem is no longer technical immaturity; it is a failure of management discipline ... Executives too often tell organizations to "use AI" before they define what AI is supposed to change. The problem deepens in organizations where strategy isn't well articulated in the first place ...

Across the enterprise technology landscape, a quiet crisis is playing out. Organizations have run hundreds, sometimes thousands, of generative AI pilots. Leadership has celebrated the proof of concept (POCs) ... Industry experience points to a sobering reality: only 5-10% of AI POCs that progress to the pilot stage successfully reach scaled production. The remaining 90% fail because the enterprise environment around them was never ready to absorb them, not the AI models ...

Today's modern systems are not what they once were. Organizations now rely on distributed systems, event-driven workflows, hybrid and multi-cloud environments and continuous delivery pipelines. While each adds flexibility, it also introduces new, often invisible failures. Development speed is no longer the primary bottleneck of innovation. Reliability is ...