How AI Can Predict Software Failures Before Users Notice Them

Disclaimer: The views expressed in this article are Ishan Sharma’s personal views and do not represent the views, positions, policies, product plans or practices of any current or former employer. The discussion is based on general software engineering principles and industry practices and does not disclose confidential or proprietary information, internal incidents, non-public metrics, implementation details or product roadmaps.

A person joins a video meeting and waits an extra second for the picture to appear. On another device, the video starts but freezes soon afterward. Most participants have no problem, so the issue may not immediately stand out in aggregate monitoring.

By the time a broader pattern becomes visible, a problematic software change may already have reached many users.

Ishan Sharma, Senior Software Engineer at Microsoft, has worked across real-time rendering, software reliability and large-scale distributed systems. His experience has exposed him to an important challenge in modern software engineering: systems often begin showing subtle signs of instability before users experience an obvious failure.

“Traditional monitoring is like a smoke detector,” Sharma says. “It tells you something is wrong, but often only after the problem has already started affecting people.”

Dashboards, logs and threshold alerts remain essential. But they often capture the visible stage of a failure: latency has risen, errors have crossed a limit or a service has entered a degraded state.

Predictive reliability tries to identify what happens earlier, when the software is still functioning but beginning to behave differently.

The warning signs are usually already there

Software failures often leave clues before they become incidents.

Memory consumption may increase gradually. Response times may become slightly slower. A component may retry an operation more frequently. Small errors may repeat without becoming serious enough to trigger a traditional alert.

In real-time video rendering, for example, engineers might observe frame times increasing, more dropped frames on a particular class of devices, changing GPU memory usage or higher power consumption.

None of these signals alone proves that a failure is approaching. Together, however, they may indicate that part of the system is moving away from its normal behavior.

“Prediction is not fortune-telling,” Sharma says. “It is identifying the patterns that tend to appear before a user-visible problem.”

This becomes particularly important in software that must operate across many combinations of hardware, operating systems and drivers.

A rendering change might perform normally on most computers while behaving differently on devices using a particular GPU, graphics driver or operating-system version. Aggregate metrics can hide the issue because the majority of users remain unaffected.

At large scale, however, even a relatively small device segment can represent a meaningful number of users.

A similar pattern appears in data and cloud infrastructure.

A poorly tuned configuration might cause a workload to run more frequently than necessary, consume additional computing resources or repeatedly enter a degraded state. Nothing appears frozen on a user's screen, but the operational impact can continue growing in the background.

“The visible symptoms can be very different,” Sharma says. “One user may experience degraded video while another system may experience inefficient processing. In both cases, the system often starts drifting before the full impact becomes obvious.”

Why fixed thresholds miss important problems

Most traditional alerts depend on limits selected in advance.

Engineers may decide that a particular latency, memory level or error rate is acceptable and trigger an alert when the system crosses that threshold.

The difficulty is that normal behavior depends heavily on context.

Traffic during a busy weekday can look different from weekend activity. A high-performance computer should not necessarily be judged against the same performance profile as an older device. One data workload may naturally require substantially more processing time than another.

A threshold set too low creates constant false alarms. A threshold set too high allows meaningful problems to remain unnoticed.

Machine-learning models offer another approach.

Instead of asking only whether a number exceeds a fixed limit, a model can learn how a system normally behaves across different devices, workloads, configurations and operating conditions.

It can then ask a more useful question: Is this behavior unusual for this particular situation?

Sharma's experience with large-scale systems has shaped how he thinks about configuration and reliability, particularly when workloads evolve over time.

“A configuration may be reasonable when an engineer first chooses it,” he says. “But the workload changes, the environment changes and the original assumption may stop being correct. The system needs a way to recognize that.”

The goal is not to remove engineers from the decision-making process. It is to reduce dependence on assumptions that were made once and then left unchanged as the environment evolved.

Prediction alone is not enough

An early warning has limited value if nobody knows what to do with it.

The larger opportunity is connecting prediction with a controlled response.

A system could identify unusual behavior, estimate the likely consequences and recommend a mitigation before the problem spreads.

In a data platform, that could mean suggesting a configuration adjustment, pausing an unexpectedly repetitive process or isolating a degraded workload.

In a real-time video application, it could mean identifying that a new release is behaving differently for a particular device segment and recommending that the rollout be paused while engineers investigate.

Sharma is careful to distinguish this from giving an AI system unrestricted control over production software.

Automated actions should have limited scope. They should be logged, observable and easy to reverse. If an intervention creates an unexpected result, the system should be able to return to a known-safe state.

“A prediction that no one acts on is only an earlier warning,” he says. “But automatic action without safeguards creates a different kind of risk.”

A safer progression begins with observation.

The model can initially make predictions without changing the system. Engineers compare those predictions with actual outcomes and determine whether the signals are reliable.

Once the model proves useful, it can begin recommending responses.

Automation can come later, starting with narrow, low-risk and reversible actions.

AI can also shorten the investigation

Detecting that a problem is developing does not automatically explain why it is happening.

A regression may be related to a particular hardware configuration, software dependency, recent deployment or configuration change. Finding that relationship manually can require engineers to examine telemetry, logs, deployment histories, code changes and previous incident reports.

During a live incident, that creates another problem: too much information.

AI-assisted reliability tools can help organize that evidence.

An AI system could examine operational data, identify which signals changed around the same time and provide engineers with several possible explanations to investigate.

“When an incident starts, engineers often face too much information rather than too little,” Sharma says. “An AI assistant can organize the evidence and help the team begin with a reasonable hypothesis.”

The engineer still decides whether the explanation is credible and whether a proposed response is safe.

The role of AI is to reduce the time spent manually gathering and connecting information, not to replace engineering judgment.

Trust remains the hardest requirement

Predictive systems will inevitably make mistakes.

False positives can create another form of alert fatigue. False negatives can create misplaced confidence. Models trained on incomplete telemetry can also misunderstand what represents normal behavior.

That is why Sharma considers explainability essential.

Before recommending a rollback, configuration change or other intervention, a predictive system should show engineers which signals changed, which environments appear affected and what recent events may correlate with the anomaly.

Engineers should also understand what the proposed action will change and what will happen if the intervention does not work as expected.

“Engineers will not trust a black box with a major production decision just because the model says it is confident,” Sharma says. “The reasoning has to be understandable, and the action has to stay within clear boundaries.”

For organizations exploring predictive reliability, Sharma recommends beginning with one recurring and costly class of failure rather than attempting to make an entire software platform self-healing at once.

First, identify and instrument the signals that tend to appear before the problem.

Then allow the model to learn what normal behavior looks like.

Run it in observation mode and measure whether its warnings are useful.

Only after establishing sufficient confidence should organizations consider allowing the system to recommend—or eventually perform—limited corrective actions.

The most successful result may be something the user never notices.

A video session begins normally. A data workload completes as expected. There is no frozen screen, unnecessary resource consumption or support ticket.

The software recognized that something was beginning to go wrong early enough that the customer never had to notice it.

Published on: Saturday, September 12, 2026, 03:01 PM IST