Sep 16, 2025 · 3 min read · Production, Reliability, and Scale
When the Services Were Healthy but the Workflow Was Slow
Every health check was green, but an important workflow was too slow for the users. The services were available, but that didn’t mean the operation was usable.
On an enterprise platform at Softcraft, we had a period when the application was technically available. The services were running. Health endpoints returned successfully. The database accepted connections, and infrastructure dashboards didn’t show a complete outage. Users were still struggling with an important workflow because requests had become slow and inconsistent during heavier periods. According to the uptime metric, the system was healthy. For the people waiting for this workflow, it wasn’t.
What Users Could Actually Do
Infrastructure availability matters. A service that’s not running can’t help anyone. But a running service is only the first layer of reliability. If an API responds after the user already tried again, the response may be successful but useless. If one step in a workflow continues timing out, the rest of the platform being healthy doesn’t solve the user’s problem. If data is old, a fast page can still lead to the wrong decision. “Is the system up?” wasn’t enough. We also needed to know if people could complete the operation the system existed to support.
The Complete Workflow
The workflow crossed application code, database queries, and internal integrations. Each component looked acceptable when viewed separately. The problem appeared in their combined behavior under real usage. A slower query increased the time a request held resources. Concurrent requests added pressure. A dependent call contributed additional variation. No single component had failed completely, so no binary health check could explain the experience. We needed measurements that followed the business operation: end-to-end latency, error rates for the specific workflow, and behavior during the periods when users reported problems. Once we looked at the operation instead of only the infrastructure, the priorities became clearer.
The Signals We Were Missing
Technical metrics are most useful when they connect to something the user is trying to do. CPU usage can help explain a slowdown, but it doesn’t tell us whether a case was registered successfully. Queue depth is important, but the age of the oldest business operation may communicate urgency more clearly. An average response time can look healthy while a smaller group of users experiences severe delays. We started paying more attention to the slowest requests in critical workflows, not only broad averages. We also connected technical failures with operation identifiers so support reports could lead to evidence instead of guesses. Infrastructure monitoring still mattered. We added what was missing: whether an important operation was actually usable. Words such as “available,” “degraded,” and “healthy” need a shared meaning. If a core workflow is consistently timing out, calling the platform fully operational creates confusion even if every service process is running. Teams make better decisions when the status reflects user impact. That can mean defining service objectives around successful operations and acceptable latency, not only process uptime.
Our dashboards weren’t wrong. They showed that the processes were running, the database accepted connections and the infrastructure hadn’t failed completely. They just didn’t show the part users were complaining about. Once we added measurements for the complete workflow, the reports from users and the technical data finally described the same problem.