Every business application encounters failures: an integration times out, a payment is rejected, a file cannot be processed or a scheduled job stops halfway through. The important question is not whether errors will occur, but whether the system fails safely, gives the user an honest explanation and tells the right person what needs attention.
Error handling describes what the application does when it cannot complete an operation. Operational alerts tell the support or technical team that intervention may be required. They are different from routine messages sent to customers or staff about normal business events.
Identify failures from the business process
Begin with the process map and examine each step that depends on data, a third-party service, a scheduled task or a manual decision. Ask what can fail, how the failure affects the business and whether the process can continue safely.
A useful failure register includes:
| Field | What to define |
|---|---|
| Operation | The action the system was attempting. |
| Failure condition | The specific condition that prevents completion. |
| User outcome | What the user sees and whether their work is preserved. |
| System outcome | Whether the action is cancelled, queued, retried or completed partially. |
| Business impact | The consequence if no one intervenes. |
| Owner | The role responsible for investigation or recovery. |
| Alert rule | When an operational alert is raised and how it escalates. |
| Recovery evidence | How the team confirms the issue is resolved. |
Design safe behaviour for the user
A user-facing error message should explain what happened in plain language, what has and has not been saved, and what the person should do next. It should not expose database messages, server paths or internal identifiers that are meaningful only to a developer.
Where possible, preserve the user’s input. If a long form fails during submission, forcing the person to re-enter everything turns a technical problem into a customer-service problem. If preserving the data is not safe, state that clearly rather than giving false reassurance.
Useful messages distinguish between:
- a validation problem the user can correct;
- a temporary service problem that may succeed later;
- a permission or account restriction;
- a failure that has been recorded and needs support intervention.
“Something went wrong” can be a final fallback, but it should not be the standard response for every failure.
Prevent partial and duplicate processing
Some failures are dangerous because the system completes only part of an operation. A record may be created but the confirmation email may fail; a payment may succeed but the order status may not update; an external service may process a request even though the local application times out.
For each critical workflow, specify what counts as complete and what happens if one step fails. Repeating an operation must not create a second payment, duplicate order or repeated customer message. The development team should explain how retries are made safe and how uncertain outcomes are reconciled.
Classify operational severity in business terms
Not every error deserves an urgent alert. A single failed report export may be a support issue. A failure affecting every login attempt is an incident. Define severity using impact and urgency rather than technical wording.
| Level | Typical business meaning | Expected response |
|---|---|---|
| Critical | A core service is unavailable, data integrity may be at risk or a security-sensitive process is failing. | Immediate alert, named owner and escalation if not acknowledged. |
| High | A major workflow is blocked for a group of users or an important integration is repeatedly failing. | Prompt investigation during the agreed support window. |
| Medium | A limited function is degraded or a workaround exists. | Create a support item and review within the normal queue. |
| Low | An isolated, non-blocking issue with little immediate impact. | Record for trend analysis or future correction. |
The exact response times belong in the support arrangement. The application specification should still define enough to route each class of failure correctly.
Alert on conditions that require action
An operational alert should lead to a decision or action. Alerting on every individual error creates noise and hides the pattern that matters. Better rules may alert when:
- a critical operation fails once;
- the same lower-severity failure occurs repeatedly within a defined period;
- a queue grows beyond an agreed operating range;
- a scheduled process does not complete by its expected time;
- an integration has been unavailable long enough to affect customers;
- a retry limit is reached;
- data reconciliation shows an unexplained difference.
Alerts should contain the affected service or process, the time, the scale of impact, a safe reference for investigation and the first recovery step. They should not include secrets or unnecessary personal data.
Define ownership and escalation
Sending an alert to a shared inbox is not an operating model. Define who is expected to acknowledge it, who investigates it and who decides whether customers or business leaders need to be informed.
A practical escalation path records:
- the primary owner during and outside normal working hours;
- the acknowledgement period;
- the next person or team if no acknowledgement is received;
- the point at which business continuity or incident-management procedures begin;
- the authority to pause a process, disable an integration or roll back a release.
Do not design a 24-hour alerting process unless someone is genuinely available and authorised to respond. An unattended alert channel creates false confidence.
Prepare recovery instructions, not just notifications
For common failures, the alert should point to a short recovery procedure. This may explain how to check the provider status, inspect the queue, retry a safe operation, switch to a manual process or escalate to a supplier.
Keep recovery guidance understandable and current. A long technical document that no one has tested is less useful than a concise runbook with clear checks, decisions and rollback steps. Record who owns each procedure and when it was last exercised.
Plan logging and evidence
The system needs enough information to reconstruct what happened without recording everything indefinitely. Logs should identify the operation, timestamp, outcome and a traceable reference. Sensitive values should be protected or omitted.
Business events and technical errors serve different purposes and should be distinguishable. A support user may need to see that a notification failed, while detailed diagnostic information remains restricted to authorised technical staff.
Write acceptance criteria for failure scenarios
Error handling cannot be accepted by demonstrating only successful transactions. Include scenarios such as:
- The payment provider times out after receiving a request, and retrying does not create a duplicate charge.
- A document scan fails, the file is not marked as approved, and the responsible team receives one actionable alert.
- A scheduled import misses its completion time, and the named operator is alerted with the affected batch reference.
- A user’s form input is retained after a temporary submission failure.
- An alert is escalated when the primary owner does not acknowledge it within the agreed period.
- Closing the incident stops further duplicate alerts while preserving the event history.
Questions to put to a supplier
- Which critical workflows can complete only partially, and how are those states detected?
- How does the system prevent duplicate processing during retries?
- Which failures are shown to users, and which details remain restricted?
- How are severity, alert thresholds and escalation routes configured?
- What happens when the alerting service itself fails?
- How long are logs retained, who can access them and how are sensitive values protected?
- What evidence will demonstrate that recovery and escalation work before launch?
Practical next step
Select the five workflows whose failure would cause the greatest business harm. For each one, document the safe user outcome, the operational alert, the owner, the recovery procedure and the evidence required to close the incident. That small, risk-led exercise is more valuable than a generic requirement to “handle all errors”.