What are the most common causes of live site failures?

Common causes include poor custom code quality, conflicting third-party extensions, misconfigured server environments (caching, database), and insufficient or absent ongoing maintenance. Often, it's a combination of these factors creating performance bottlenecks or functional errors.

How quickly can a struggling site be stabilised?

Initial stabilisation can often begin within 24-48 hours, focusing on critical issues like site downtime or payment processing. Full resolution of underlying problems, however, can take weeks or months depending on complexity, requiring a structured approach to rescue and remediation.

What data should I prepare before seeking help?

Prepare detailed descriptions of symptoms, including specific error messages, URLs, browser types, and approximate times of occurrence. Access to server logs, application performance monitoring (APM) data, and a summary of recent deployments or changes are also crucial.

What is the role of a code audit in a rescue situation?

A code audit identifies inefficient, insecure, or conflicting code causing performance issues, bugs, or security vulnerabilities. It forms the basis for targeted remediation efforts, ensuring fixes address root causes rather than just symptoms. This is vital for long-term platform health.

Could a rescue lead to a full replatforming?

Yes, in severe cases where the existing platform is fundamentally flawed, insecure, or unsalvageable due to extensive technical debt, a rescue assessment may conclude that replatforming is the only viable long-term solution. This is usually a last resort, considered when remediation costs outweigh the benefits.

Talk to an expert

Issue 039PositionRescueRef 132

What a good rescue plan looks like when a site is already live

When a commerce site is underperforming or failing, a structured rescue plan identifies the root causes, stabilises the platform, and establishes a clear path to recovery, prioritising business continuity and data integrity.

Neil Boughton· Technical Director

29 Sept 20255 min readReviewed September 2025

"A rescue is not merely patching; it is concentrated effort to stabilise, diagnose, and remediate systemic problems while minimising commercial impact."

Written by

Neil Boughton

Technical Director

29 years at iWeb

LinkedIn →Speak with Neil about your brief →

Neil leads platform architecture and integration strategy at iWeb. He has designed ERP and commerce integration patterns across manufacturing, wholesale and retail, and writes about operational resilience, release governance, observability, and the infrastructure decisions that determine whether large programmes stay stable under pressure. Bias toward durable, measurable systems over architectural theatre.

Next step

Take this conversation private.

If this note matches the brief on your desk, the version we'd write for your platform, sector and trade-account model is the work itself. Send a short brief and a senior lead replies inside 48 hours.

Talk to an expert Back to The Record →

Operational notes worth reading next.

What a senior engineer actually does in the first 48 hours of a rescue project

Why most rescue projects are actually replatforms in disguise

Rescue benchmark: build pipeline health, and the three numbers that predict the next outage

A regular round-up of new notes.No content marketing.

Take this conversation private.

A regular round-up of new notes.
No content marketing.