“It's slow and nobody can say why”
An application, report or transaction has been slow for weeks. Internal teams and even the software vendor have run out of ideas, or out of time.
System performance experts
Find the real constraint, before it costs you the client.
Kritical investigates difficult performance problems: the slow application, the intermittent stall, or the storage array that looks fine on the dashboard while the business waits. We use Windows Internals knowledge, cross-platform experience and Microsoft tracing tools, then turn what we find into a clear plan you can act on.
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.
Three situations that land on our desk.
You do not need a perfect problem statement to start. These are practical places from which an investigation can begin.
A migration or upgrade changed something
Performance was fine before a platform change, storage migration or application upgrade, and nobody has proven what shifted.
The board wants an answer, not a guess
A performance problem is now a business risk. You need an independent, evidence-based account of the cause before you spend on a fix.
Treat performance as a whole-system problem, not a supplier boundary.
Slow services rarely respect the org chart. A delay visible in an application may originate in a thread, a query, an identity call, a network path, a virtualisation layer or a storage queue — or an interaction between several of them. We establish the affected transaction and time window, then correlate evidence across every relevant layer, so a difficult fault does not get closed as “works as designed”.
Treat performance as a whole-system problem, not a supplier boundary.
- Windows & MicrosoftInvestigate Windows internals, services, Active Directory dependencies and Microsoft platform behaviour.
- Cross-platform systemsFollow work across Windows, Linux, Unix, virtualisation, identity and shared infrastructure.
- Critical applicationsTrace the user-visible transaction through application and infrastructure dependencies.
- Enterprise storageAssess latency, throughput, queueing, resilience and host-to-array behaviour in context.
What a Kritical performance engagement includes.
Every investigation is scoped in writing before evidence collection starts, and leaves you with more than a slide deck.
- A bounded evidence-capture plan Agreed scope, tools, capture window and approvals before anything is traced on a live system.
- A dependency-aware findings report What is constrained, what is merely busy, what evidence is still missing — each conclusion tied to its evidence.
- A remediation plan with a rollback Changes ranked by risk, with a defined way to reverse them and a comparable workload to test against.
- A verification run The same transaction, measured the same way, after the change — so “fixed” is a result.
Move from symptom to a testable explanation.
We agree what slow means for the people or systems affected, preserve timestamps and change context, and choose evidence that can distinguish between plausible causes. A bounded investigation may combine performance counters, ETW traces read in Windows Performance Analyzer, Sysinternals tools, application logs, storage and network topology, configuration and workload observations. Hypotheses that remain unproven stay labelled as hypotheses — we do not round an educated guess up to a finding.
Vendor-neutral craft.
Kritical's performance practice is led by a senior engineer whose background spans Microsoft platforms, Windows internals, storage, virtualisation, backup, networking and mixed operating environments. The toolkit is deliberately vendor-neutral: Event Tracing for Windows and Windows Performance Analyzer for what the operating system did, the Sysinternals suite for process, handle and file-system behaviour, and the native tools of whichever platform sits in the path — not one product's dashboard treated as the whole truth. That breadth matters when a fault sits between teams rather than neatly inside one vendor's support contract.
How the work is priced.
A first investigation is scoped as fixed-price work once we know the transaction, the environment and the evidence available, so you know the cost before capture begins. Where the scope is open — an intermittent fault that needs an observation period, for example — we price it in stages, with a decision point after each one. Ongoing performance oversight, if you want it, is a separate, explicitly scoped arrangement.
Get a scoped quote
Send the affected transaction, its business impact and any evidence you already have.
What happens after you send the first email.
The first call establishes the transaction, its impact and the evidence realistically available, and results in a scoped, priced plan. Subject to the agreed scope and available evidence, an initial phase can move from evidence capture through a dependency-aware finding to an agreed remediation plan with a defined rollback. Immediate restoration, permanent correction and longer-term capacity planning are treated as different jobs, so the urgent fix does not quietly become the entire strategy.
Choose the next evidence path for a difficult constraint.
A performance investigation can expose an identity, access or control dependency. Confirm who owns each boundary, then move from the measured constraint into the security investigation when the evidence requires it.
Choose the next evidence path for a difficult constraint.
- Agree the responsibility boundary before captureSee who owns the systems, evidence, approvals, changes and ongoing operation before the investigation starts.
- Check the security path behind the constraintMove from performance evidence to cybersecurity when identity, access, controls or response ownership is part of the cause.
Questions before you enquire
Can you investigate an intermittent slowdown?
Yes. We first establish when it occurs, what is affected and which evidence can be captured safely. The scope may include an observation period if the condition cannot be reproduced on demand.
Do you only work on Windows?
No. Windows Internals is a specialist strength, and investigations regularly span Apple, Linux, Unix, compute, virtualisation, storage, networking and application dependencies in the same engagement.
We already asked our vendor and they said everything looks fine.
That is a common starting point. A vendor's own telemetry often only covers their own product; we correlate evidence across the whole path and tell you where the vendor's view runs out.
Will this turn into an open-ended retainer we can't get out of?
No. The first piece of work is scoped and priced as its own engagement. Ongoing oversight is a separate decision you make afterwards, with its own scope and price.
Can you work with our vendors and internal teams?
Yes. We keep a shared record of findings and decisions while each team retains responsibility for its own systems, approvals and vendor support obligations.
What if the evidence points somewhere you don't specialise?
We say so. The investigation follows the dependency instead of forcing a Windows-only or single-vendor answer, and we tell you plainly when a specialist vendor needs to take the next step.
Let’s define the next step.
Tell us what you want to achieve, what you have today and when it matters.