Your website can be online, fast and apparently healthy while something important behind it has stopped working.
A booking form may depend on an external reservation system. An enquiry might need to reach a CRM. An online purchase could involve a payment provider, stock system or delivery service. Increasingly, websites are connected to other systems through application programming interfaces, usually shortened to APIs.
An API is simply a defined way for one piece of software to communicate with another. That connection can remove repetitive work and create much better customer journeys. It also introduces a dependency: part of your website now relies on a system you may not control.
The website being online does not mean the whole service is working
Traditional uptime monitoring often answers a fairly narrow question: can somebody reach the website? That matters, but it does not prove that every customer journey is functioning.
A visitor might browse products successfully while the stock connection has failed. A membership website could allow somebody to update their details while synchronisation with another business system has stopped. An enquiry form may display a reassuring confirmation even though the CRM that should receive the enquiry is unavailable.
This is one reason to think about availability in terms of complete journeys rather than a single server. GOV.UK's guidance on service availability recommends understanding the systems a service depends upon, including third-party dependencies and their expected availability.
The same distinction is explored in our guide to what a 99.9% uptime promise actually means. A server can be available while an important piece of functionality is not.
Decide what failure should look like before it happens
When an external service becomes unavailable, the right response depends on what the integration is doing.
Some actions genuinely need an immediate response. A website may need confirmation from a payment service before it can tell a customer that payment succeeded. In other cases, waiting for the external system is unnecessary. A website might safely store an enquiry and send it to the CRM later.
GOV.UK's guidance on depending on third-party APIs suggests several possible responses, including giving users another route, queuing an action for later or providing an alternative system. It also recommends being clear with users when a third-party failure affects the service.
For each important integration, useful questions include:
- What part of the customer or staff journey depends on it?
- Does that action have to happen immediately?
- Can information be stored safely and processed later?
- What should the visitor see while the external service is unavailable?
- Could staff continue the process manually if necessary?
- How will the business know that something has failed?
The goal is not to build an elaborate backup system for every API. It is to understand the consequence of failure and make a deliberate decision about what should happen.
Retrying can help, but careless retries create new problems
Some API failures are temporary. A network connection might briefly fail, a service may be overloaded or a request may time out. Trying again after an appropriate delay can therefore be sensible.
It is not sensible to retry everything indefinitely.
Microsoft's guidance on handling temporary faults recommends distinguishing between problems that may resolve themselves and errors where repeating the same request is unlikely to help. It also warns against excessive or immediate retries, which can place even more pressure on a struggling service.
Retries become especially important when an action changes something. Imagine a customer submits an order and the website does not receive a clear response. Did the external system create the order before the connection failed, or did nothing happen?
Blindly submitting it again could create a duplicate.
This is where a technical property called idempotency can matter. In plain English, it means designing an operation so that repeating the same request does not accidentally repeat its effect. Amazon's guidance on safe API retries explains how unique request identifiers can help systems recognise that a retried request relates to an operation they have already seen.
A business owner does not need to design that mechanism, but it is worth asking how an important integration handles uncertain outcomes and repeated attempts.
A failed integration needs to become visible
One of the awkward things about integration failures is how quiet they can be.
If the entire website disappears, somebody will probably notice. If a background process stopped sending enquiries to another system at 2.15am, the problem might remain hidden until a member of staff wonders why the inbox has been unusually peaceful.
Monitoring therefore needs to match the importance of the dependency. That might involve recording unsuccessful API requests, watching queues for growing backlogs, detecting delayed background jobs or alerting somebody when repeated failures occur.
An alert also needs an owner. Sending automated warnings to an abandoned mailbox does not create much resilience.
For websites with substantial operational dependencies, platform-level monitoring can extend beyond basic website availability to background processes, integration points and external services. The appropriate level of monitoring will depend on how much the business relies on those systems.
Recovery includes dealing with what happened during the outage
A service coming back online does not necessarily mean the incident is finished.
There may be queued work waiting to process, transactions with uncertain outcomes or information that reached one system but not another. Staff may need to identify what failed during the outage and confirm that it has since been processed correctly.
This reconciliation stage deserves attention when an integration carries commercially important information. If orders, payments, bookings or customer records are involved, simply seeing a green status indicator again may not provide enough assurance.
External dependencies are not inherently a weakness. APIs can make websites substantially more useful and can remove large amounts of manual administration. The risk appears when an important dependency exists without anybody deciding what failure means.
Start with the integrations that would hurt most if they stopped working. Identify what depends on them, decide what customers and staff should experience during an interruption, establish how failures will be detected and determine how missed or uncertain actions will be reconciled afterwards. A dependable integration is not one that never encounters failure. It is one where failure has already been considered.
