technical-article · 2026-10-16 · Bleu · 6 min · en

> How we investigated a slow application, found the cause, and monitored what happened after the fix.

Based on Juliano Quatrin Nunes's presentation at Bleu Bytes.

You open a page to get some work done and wait, refresh, try again, and ask whether anyone else is having the same problem. The team responsible for the system starts investigating, but still can't explain why this is happening.

For a founder or manager, the challenge is deciding what to do next while work remains stalled (and, if you're not working with a company like Bleu, there's also the challenge of waiting to hear back from the IT guy who never replies, haha).

You might need to increase server capacity, fix a feature, or review a recent update, but each hypothesis involves a different kind of work and investment. We need to know what supports that decision.

We went through this on a project for a consultancy in the mining sector. We were replacing an old system built on technology that no longer had adequate support, and the new system added features for work that had previously been manual, such as retrieving information from regulatory agencies and entering internal deadlines.

One day, some pages weren't loading, and the internal team began reporting difficulties using the application. We already knew which pages mattered most to their daily work, especially those for cases and alerts, and used the dashboards to investigate what was happening at that moment.

The data helped us locate the fault, and we resolved the problem quickly. After the fix, we continued monitoring the application to check whether the pages were loading again and whether any users were still affected.

A complaint about slowness describes what someone sees on their screen, but still leaves several possible causes open. To investigate, we need to track how long operations take, how often they run, and what happened during the period when the problem occurred.

This capability is called observability. It allows us to understand a system's behavior through the data it produces, as defined by [OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer/).

On this project, we organized that information into dashboards and began comparing periods of slowness with the application's usual behavior. We could check whether an operation was taking longer, running at a different frequency, or spending a large share of its response time on a particular step.

That gave us a way to check our hypotheses before choosing what to change.

When we checked the dashboard, we found an increase in response time, but the volume of calls guided the investigation, which needed to be fast and effective: deadlines for more than 40,000 cases depended on that workflow.

Under normal conditions, the most frequently accessed operations received around 40 to 50 calls every five minutes. During the incident, a single operation reached approximately 3,000 calls over the same interval.

By examining the logs and code, we found a bug in the page: under certain conditions, it sent a request to the server and repeated that request while waiting to finish loading. The loop generated more calls and made loading harder, sustaining the behavior that was causing the overload.

We fixed the code and continued monitoring the dashboard. After deployment, however, new spikes appeared because some people still had the previous version open in their browsers and were continuing to generate repeated calls.

We needed to ask those users to reload the application and add a limit to contain the excess requests. That protection contained the overload caused by older versions, while the data allowed us to track the effect of the fix and the calls that were still coming in.

You don't need to know the application's architecture to follow an investigation. You need to understand how the team arrived at the identified cause and what they will continue monitoring after the fix. These questions help make the conversation more concrete:

| Question | What the answer helps you understand | |---|---| | Which tasks are affected? | Where slowness is getting in the way of work | | What has changed compared with normal behavior? | Which hypotheses the data supports and which deserve investigation first | | What evidence supports the identified cause? | How the team connected the observed problem to the proposed change | | How will we check whether the fix worked? | Which data will be monitored and which tasks will be checked with users | | Who might still be experiencing the problem? | Whether older sessions or other situations need attention |

Starting with hypotheses is part of an investigation. On this project, we had questions about the infrastructure, communication between parts of the application, and the code, but we only made progress once we began checking those possibilities against system data.

The same applies to the fix. If we had stopped monitoring immediately after deployment, sessions running the previous version would have continued causing the problem without us understanding why.

The consultancy's system was used by a small number of people to track thousands of cases, and its slowness disrupted the work of those who depended on it to manage all the deadlines.

That needs to factor into performance assessments. A tool used throughout much of the working day can delay the entire routine, even if it has a small user base, and the tasks that matter most to those people should guide what we measure and investigate.

After the incident, we used the same data to examine database queries and make other adjustments. We could see which steps took longer and assess where a code change might improve response time.

The modernization also needed to be assessed through that everyday use. New features were part of the delivery, as were understanding why a page was slow and checking whether the changes improved work for the people who depended on it.

It depends on the cause. More capacity may be necessary when the available resources can't meet demand, but you need to check what is driving that demand. In this case, we found a bug that repeated calls to the server, and we needed to fix that behavior.

It's the ability to understand what happens inside a system: where it becomes slow, why a failure occurred, and how that affects the people using it. With this data, the team can identify the cause of problems and check whether the adjustments resolved them.

Monitor the data after the change, using the same measurement criteria, and check tasks with users. In this case, that verification showed that some people still had the previous version open and were continuing to generate repeated calls.

Consider how much work depends on it. An application used by a small number of people may be needed to track thousands of cases or meet deadlines, and the information collected should help investigate problems that affect those tasks.

Themes: observability · performance · modernization