A revenue-facing service slows down under real load
It works in testing and struggles the moment genuine demand arrives.
Application and workload performance
Protect the performance of the application the business cannot run without.
Kritical helps application owners investigate slow, unstable or capacity-constrained services by connecting the user experience with application, data and infrastructure evidence — so the fix targets the actual constraint, not the easiest metric to change.
On this page
Choose where to start.
Jump to the part that matches the problem or decision in front of you.
Use the arrows or scroll to see every card.
Who brings us a critical application problem.
These three situations provide a practical starting scope for the work.
An intermittent failure that only shows up in production
Retries, timeouts or errors that the development team cannot reproduce on demand.
A capacity decision with money attached
You need evidence before committing to a scale-up, a re-platform or a vendor's recommended upgrade.
Define the service before measuring the stack.
We begin with the user journey or machine transaction, its business timing and the conditions under which it degrades. That definition guides correlation across front ends, application services, integrations, databases, identity, networks and infrastructure. It also prevents a technically convenient metric from replacing the outcome that users need.
Separate saturation, contention and failure behaviour.
Slow responses can result from scarce capacity, serial work, lock or queue contention, repeated failure, retry storms, dependency timeouts or inefficient use of otherwise healthy resources. We build and test hypotheses using the evidence available, identify missing instrumentation, and preserve the difference between correlation and cause.
- Latency and throughput Relate response time, concurrency and completed work to demand.
- Data and integration Inspect query, queue, API and external-service behaviour in the transaction path.
- Resilience under pressure Understand timeout, retry, back-pressure and recovery behaviour when dependencies slow or fail.
What the engagement leaves you with.
A written, evidence-backed answer you can act on — and defend to your own board if you need to.
A named bottleneck, ranked by confidence
Distinguishing what the evidence proves from what it merely suggests.
A change plan with a rollback
What to change, in what order, and how to reverse it if the result is not what was expected.
A before-and-after comparison
The same workload, measured the same way, so improvement is a number rather than an impression.
Choose changes that can be compared and rolled back.
Before changing anything, agree what should improve and how to measure it. We compare the same workload after the change, then hand over the remaining risks, monitoring and ownership — so a fix made under pressure does not become an unexplained fact of life six months later.
How the work is priced.
A first investigation is fixed-price once the transaction, environment and available access are agreed. Where an application vendor or a specialist third party must also be involved, we say so up front rather than discovering it mid-engagement.
Get a scoped quote
Send the affected application, its business impact and when it degrades.
What happens after you name the application.
The first call establishes the transaction, its business impact and the access available, and ends with a scoped, priced plan rather than a guess. Subject to the agreed scope and available evidence, an initial phase can move from evidence capture to a ranked finding and a change plan with a rollback attached.
Protect the critical workload while checking its security path.
A critical application needs a performance answer that respects its security and ownership boundaries. Define who can change what, then choose the evidence path that explains the business impact.
Protect the critical workload while checking its security path.
- Make application responsibility explicitSeparate application, data, infrastructure, security and recovery ownership before changing a critical workload.
- Check the controls behind the workloadMove from application performance evidence to cybersecurity when access, identity, endpoint or response controls affect the transaction.
Questions before you enquire
Can you investigate software you did not build?
That depends on what can be inspected, what access is available and whether the product vendor or developer must join the investigation.
Can you work during a major incident?
Urgent work depends on availability, safe access and an agreed incident role. Ongoing on-call coverage is not implied.
Can you improve monitoring as part of the work?
Yes. Instrumentation gaps can be documented and an observability improvement scoped, with data handling and ongoing ownership agreed.
Our vendor says we just need to scale up. Can you check that first?
Yes — that is exactly the kind of recommendation worth testing with evidence before you spend on it. Scaling can mask a contention or configuration problem instead of fixing it, and it is usually the more expensive option to try first.
Can you tell us before spending money whether scaling will help?
Often, yes. If the evidence shows genuine saturation, scaling is a reasonable answer and we will say so. If it shows contention, retries or a design limit, we will tell you that instead of letting you buy hardware that will not fix it.
What do you need from our team to start?
A named business transaction, the systems and access involved, and someone who can approve a capture window. We can help define the transaction if it is not already written down anywhere.
Let’s define the next step.
Tell us what you want to achieve, what you have today and when it matters.