Support

Troubleshooting

Finding the actual cause, not the nearest plausible one

How this is usually engaged

Charged on time rather than fixed price, because nobody can honestly quote a fixed fee to find something not yet identified. We agree a review point at an initial budget: at that point you get what we have found, and you decide whether to continue. Sometimes the answer is that the cause is in a third-party system and the next step is theirs, not ours.

Practice
Support & Maintenance
Sectors
4 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

Summary

Diagnostic work on systems that are failing, slow or behaving inconsistently — including systems we did not build and problems that have already defeated one attempt at a fix.

01What this solves

The problem this addresses

Some faults resist the obvious approach. They appear only under load, or only for one customer, or only on a Monday, and each attempted fix either changes nothing or moves the symptom somewhere else. What usually goes wrong is that the fault was never actually reproduced: a plausible cause was identified, a change was made, and the problem appeared to go away for a while. Time then gets spent on a sequence of guesses, which is more expensive than the diagnosis would have been.

02Capabilities

What is included

01

Fault reproduction

Establishing a reliable way to trigger the failure, or instrumenting the system to capture it when it happens naturally. Everything else is guesswork until this exists.

02

Performance diagnosis

Profiling and query analysis to find where the time is actually spent, which is regularly not where the team assumed. Measured before and after any change.

03

Data integrity investigation

Tracing how records reached an impossible state, identifying the code path or missing constraint responsible, and assessing how much existing data is affected.

04

Integration failure analysis

Working out which side of a boundary is at fault by examining traffic and timing, so a supplier conversation can start with evidence rather than an accusation.

05

Deployment and environment issues

Faults that appear in one environment and not another, traced to configuration, versions or infrastructure differences rather than to the application code.

06

Post-incident review

A written account of what happened, why it was possible and what would prevent a recurrence — focused on the system and its controls rather than on individual blame.

03Use cases

Where this work usually starts

01

Intermittent failures nobody can reproduce

A fault that appears a few times a week with no obvious pattern, where two rounds of speculative fixes have already been tried.

Logistics & Transport

02

A system that has become slow over time

Nothing changed, but pages that used to load promptly now take seconds. Usually data volume meeting a query written for a smaller table.

E-commerce

03

Disputed responsibility between suppliers

Two vendors each say the fault is with the other. An independent diagnosis settles it with evidence instead of argument.

Professional Services

04Approach

How we approach it

We work from evidence rather than intuition. First we establish what the failure actually is and find a way to reproduce it or capture it happening, using logs, traces, timing data and the change history. Then we narrow the cause by elimination until it can be demonstrated rather than argued. We say plainly which findings are proven and which remain a hypothesis, and we recommend the minimum change that addresses the cause — separating it from the wider improvements the investigation may have uncovered.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Triage

    What is failing, for whom, since when and how often. Also whether anything can be done immediately to reduce the impact while the cause is investigated.

  2. 02

    Evidence gathering

    Logs, traces, metrics, database state and the change history. The change history is usually the fastest route to a recently introduced fault.

  3. 03

    Reproduction

    Establishing a reliable trigger in a safe environment, or adding instrumentation to capture the failure in the act.

  4. 04

    Isolation

    Narrowing by elimination until the cause can be demonstrated. We distinguish clearly between what is proven and what is still a hypothesis.

  5. 05

    Fix and verify

    The minimum change applied, verified against the reproduction case, and the fault confirmed absent over an agreed observation period.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • Diagnosis reportWhat the fault is, how it was reproduced, the demonstrated cause and the evidence for it.
  • Reproduction caseA test or documented procedure that triggers the fault, so any fix can be proven.
  • Recommended fixThe minimum change addressing the cause, separated from wider improvements found along the way.
  • Impact assessmentHow much data or how many users were affected, and what remediation that implies.
  • Post-incident write-upTimeline, contributing factors and preventative measures, without individual blame.
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

  • TypeScript
  • Node.js
  • Python

Data & Storage

  • PostgreSQL
  • Redis

DevOps & Operations

  • Docker
  • Grafana
  • Sentry
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Diagnostic work often touches live data, so we prefer to reproduce in a non-production environment with masked data and take only the production access a specific question requires — agreed in advance, time-limited and logged. Where we must capture data to investigate, we agree what is captured, where it is held and when it is destroyed. If the cause turns out to be a security weakness, we report it through a restricted channel rather than in the general write-up.

09Questions

Asked before we start

Can you quote a fixed price to fix it?

Not honestly, before diagnosis. Any fixed price for an unidentified fault is either padded to cover the worst case or will run into a change request. We work to an agreed initial budget with a review point: you get what we have found so far and decide whether to continue.

Will you work on a system you did not build?

Yes — that is most of this work. We need access to the source code, the environments and whatever logging exists. Where the system has no useful logging, the first part of the job is adding enough instrumentation to see what is happening, and we will tell you if that is the case before spending your budget guessing.

What if you cannot find the cause?

It happens, particularly where the fault sits inside a third-party system we cannot see into or where the evidence has already been lost to log retention. You get a written account of what was ruled out, which has real value for whoever looks next, and a recommendation for the instrumentation that would catch it on the next occurrence. We will stop and say so rather than continue billing against diminishing returns.

Can you respond to an incident happening right now?

If you already hold a support agreement with us, the escalation route and response commitments in that agreement apply. Without one, we will help where we have availability, but we cannot promise immediate attention to an organisation whose systems we have never seen — the first hours would be spent on familiarisation. If out-of-hours response matters to you, arrange it before you need it.

START HERE

Talk to us about Troubleshooting

The project brief takes about five minutes and gives us enough to have a useful first conversation about Troubleshooting rather than a generic one. If you would rather just ask a question, the short form is there for that.

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.