The Application Was Healthy. Sales Were Not.
The Application Was Healthy. Sales Were Not.
For two days, sales had dropped.
At first, this looked like a familiar production problem.
Maybe the site was down.
Maybe an API was failing.
Maybe there was an increase in JavaScript errors.
Maybe users were abandoning the journey because of performance issues.
So we started with the usual question:
What is broken?
The problem was that, according to almost every technical signal we had, the answer was:
Nothing.
The Problem Statement
We had multiple monitoring and analytics tools already in place.
AppDynamics was monitoring application health and availability.
There were no major exceptions or outages.
Adobe Analytics was tracking user activity and business metrics.
Nothing immediately stood out as an obvious explanation for the drop.
We also had LogRocket, which gave us visibility into actual user sessions.
The application was available.
The APIs were responding.
The monitoring dashboards were largely green.
Yet sales had fallen.
This is one of the more difficult types of production problems.
When something crashes, you usually have an error to follow.
When everything appears healthy, the investigation becomes much broader.
The real question was no longer:
“Is the application working?”
It became:
“Are customers actually able to complete the journey we expect them to?”
How We Identified the Problem
LogRocket had thousands of recorded user sessions.
In theory, we could manually review them.
In practice, that would mean opening session after session, watching customer behaviour, comparing patterns, and hoping that someone eventually noticed something unusual.
That did not scale.
This was where GenAI became useful.
Inside LogRocket, we had access to an AI capability that could analyse user sessions.
Instead of asking it a generic technical question, I gave it the business context:
Sales have dropped. Review these user sessions and identify whether customers are facing anything unusual in their journey.
I then divided the investigation into roughly 12-hour windows and analysed batches of sessions across those periods.
The agents started reviewing the sessions and looking for repeated behaviour.
Eventually, one pattern surfaced.
Some users were being prevented from navigating to the product detail page.
That was the clue we needed.
The Interesting Part: Nothing Was Technically Broken
At first, you might expect this to have been a routing issue, frontend exception, or failed API call.
It wasn’t.
The behaviour was caused by an existing hard-stop condition in the application.
In other words, the system was behaving according to an existing rule.
There was no crash.
There was no obvious exception.
There was no infrastructure failure.
The feature itself was working.
But under certain conditions, that feature was preventing legitimate customers from continuing their journey.
That meant the system was:
Technically correct, but business-wise damaging.
And that is precisely why the problem was difficult to identify using traditional monitoring alone.
Our observability systems were telling us whether the application was healthy.
They were not necessarily telling us whether the customer journey was healthy.
What Actually Changed
Once the behaviour was identified, the investigation became much smaller and more focused.
Instead of searching across the entire application, we now had one specific condition to investigate.
We reproduced the behaviour.
We validated the rule that was triggering the hard stop.
We checked whether that rule was still supposed to apply to those users.
Get Bharath Parsam’s stories in your inbox
Join Medium for free to get updates from this writer.
And we corrected the flow so legitimate customers could continue to the product detail page.
The important part here is that AI did not automatically fix the production issue.
It did something different.
It dramatically reduced the search space.
We went from:
Thousands of sessions + no obvious error
to:
One repeated behaviour + one condition worth investigating.
That allowed the engineering team to validate the issue and make the right change much faster.
Where GenAI Actually Added Value
A lot of conversations around GenAI still focus on obvious use cases.
Generating content.
Writing code.
Building chatbots.
Summarising documents.
Those are useful.
But this experience showed me another side of it.
GenAI can also become part of the engineering workflow itself.
In this case, it acted almost like another investigator.
It reviewed behaviour at a scale that would have been painful for a human team to review manually.
It helped surface a pattern.
The engineer still had to understand the context.
The engineer still had to validate the finding.
And the engineering team still had to decide and implement the fix.
But AI shortened the path between:
“Something is wrong.”
and
“Now we understand why.”
That is a very practical form of value.
Monitoring System Health Is Not Enough
This incident also reinforced an important lesson.
We often monitor production systems through infrastructure and application signals:
- uptime
- latency
- exceptions
- API failures
- CPU and memory
- frontend errors
All of these matter.
But a system can pass every one of those checks and still fail the customer.
A user who cannot reach a product page does not care that the API returned HTTP 200.
A customer who cannot complete a purchase does not care that the infrastructure dashboard is green.
This is why behavioural observability is becoming increasingly important.
We need to understand not only:
Is the system functioning?
but also:
Is the user succeeding?
My Takeaway
This experience changed how I think about GenAI.
I do not think AI always needs to become a separate product or a chatbot sitting beside an application.
Sometimes it should simply become another capability inside the tools we already use.
An observability tool can investigate sessions.
A support platform can classify customer problems.
A development environment can analyse code.
An analytics platform can help explain unusual behaviour.
Over time, we may stop consciously thinking:
“I am using AI now.”
It may simply become part of how we investigate, build, operate, and make decisions.
The internet followed a similar path.
There was once a time when “going online” was a separate activity.
Today, the internet quietly powers almost everything we do.
GenAI may be heading in a similar direction.
And for engineers, the important skill may not be knowing every new AI tool.
It may be knowing when AI can reduce the distance between a business problem and the insight needed to solve it.
Because sometimes the hardest production problem is not when the system is down.
It is when everything looks green, but the customer still cannot move forward.
