Most platforms do not fail in one dramatic outage. They fail slowly. Releases that used to take an afternoon now take a week. Every second deploy needs a rollback. The on-call rota is burning people out, and nobody can say with confidence what is running in production. By the time a CTO calls it a rescue, the platform has usually been failing for months.

The good news is that a struggling platform can almost always be stabilised without a rewrite. This guide sets out how to tell whether you need a rescue, what the first 30 days should look like, and how to judge whether the work is paying off. It is written for CTOs and engineering leaders in the UK and US who have to fix delivery while the business keeps running.

Signs your platform needs a rescue, not a tweak

Google's DORA research programme has surveyed more than 39,000 professionals over a decade, and its four delivery metrics are the most widely used yardstick for platform health: change lead time, deployment frequency, change failure rate and failed deployment recovery time. In the 2024 Accelerate State of DevOps report, the gap between the best and worst teams is stark:

Metric Elite teams (19% of respondents) Low performers
Change lead time Less than one day One to six months
Deployment frequency On demand, several times a day Once a month to once every six months
Change failure rate 5% 40%
Failed deployment recovery time Less than one hour One week to one month

Compared with low performers, DORA found elite teams have 127 times faster lead times, 182 times more deployments a year, an 8 times lower change failure rate and 2,293 times faster recovery from failed deployments. The same report notes that industry does not meaningfully predict performance. Regulated or "legacy" sectors are not destined to be slow.

If your numbers sit in the bottom row, or nobody can produce them at all, you need a rescue. Other warning signs are just as telling:

  • Releases are batched into large, scary deployments because small ones feel too risky.
  • Only one or two people know how to deploy, restore a database or rotate a secret.
  • Infrastructure was built by hand in a cloud console and is not in code.
  • Alerts fire constantly, so the team has learned to ignore them.
  • Cloud spend is rising faster than usage, and nobody owns it.

What a failing platform costs

Downtime is the visible cost. Uptime Institute's 2026 outage analysis reports that 57% of respondents to its 2025 survey said their most recent major outage cost more than $100,000, and for the second year running one in five said it cost more than $1 million. Uptime also found that failure to follow established procedures remains the leading driver of outages caused by human error.

That last point matters for a rescue. Many expensive incidents are not exotic technical failures. They come from steps that live in someone's head, runbooks that are out of date and manual changes that nobody reviewed. Those are exactly the things a rescue fixes first.

The hidden costs are usually larger: engineers spending their week on firefighting instead of product work, technical debt compounding, features held back because the release process is fragile, and experienced people leaving because on-call has become unbearable.

The 30-day DevOps rescue plan

A rescue is not a transformation programme. The aim of the first 30 days is to stop the bleeding, make the platform predictable and leave the team with a clear, prioritised plan. Bigger changes come after that, on solid ground. If you run machine learning workloads, the same approach applies to Kubernetes for ML.

Days 1–5: triage and baseline

Start by finding out what is actually true.

  • Measure the four DORA metrics from real data: your CI/CD history, incident tracker and version control. Rough numbers are fine. No numbers is the finding.
  • Map production. List every service, environment, database, queue and third-party dependency, and who owns each one.
  • Review the last ten incidents. Look for patterns in cause, detection time and recovery time.
  • Check the basics that end companies: backups that have been restored recently, access control, secrets handling and single points of failure.

The output is a one-page risk register ranked by likelihood and business impact, agreed with the CTO.

Days 6–15: stabilise

Fix the problems most likely to cause the next serious incident.

  • Make deployments boring. One automated pipeline per service (our CI/CD guide covers the pattern), with tests that gate the release and a rollback that has been tried, not just written.
  • Cut alert noise. Delete or downgrade alerts nobody acts on, and make sure the ones left point to a runbook.
  • Write the missing runbooks for the five most common incidents and the three scariest ones.
  • Close the access and backup gaps found in triage.
  • Freeze risky change where needed, so the team can stabilise without new fires starting.

Days 16–25: codify and speed up

Once the platform stops surprising people, make it repeatable.

  • Move hand-built infrastructure into code (Terraform, Pulumi or similar), starting with the parts that change most often.
  • Shrink batch sizes. Smaller, more frequent releases are safer releases. DORA's research has linked small batches and strong testing to better delivery for years.
  • Set service-level objectives for the services customers depend on, so "is the platform healthy?" has an objective answer.
  • Put cost on the dashboard. Tag resources by service and owner, and remove idle capacity. Our GPU FinOps guide shows how this works for AI workloads.

Days 26–30: hand over and plan

A rescue that leaves the team dependent on outside help has failed.

  • Re-measure the four DORA metrics and compare them with day one.
  • Run a game day: break something on purpose in a safe environment and let the in-house team recover it using the new runbooks.
  • Deliver a 90-day roadmap covering what to automate, what to retire and where a proper internal platform would pay off.

Rescue, platform or rebuild?

CTOs under pressure are often pitched one of two extremes: a full rewrite, or a shiny internal developer platform. Neither should be the first move.

DORA's 2024 report found that using an internal developer platform was associated with 10% higher team performance and a 6% increase in software delivery and operations performance. It also found throughput fell about 8% and change stability fell 14% compared with teams not using a platform, and that platforms built without a user-centred, product mindset become more of a hindrance than an aid.

The lesson for a rescue: stabilise first, then build platform capability where the team actually feels the pain. A rewrite is only worth it when the underlying architecture cannot meet the business's needs, and that decision is far easier to make with 30 days of real data behind it.

How to choose a DevOps rescue partner

Ask any partner these questions before you sign:

  1. What will you measure on day one and day 30? If the answer is not concrete, walk away.
  2. Who will do the work? You want experienced engineers who have run production systems, not a team learning on your platform.
  3. How do you hand over? Look for runbooks, infrastructure as code, training and a roadmap your team owns.
  4. What will you not touch? A good partner limits risk by changing as little as possible in the first fortnight.
  5. Can you show similar work? Ask for examples with before-and-after metrics.

At Scalexa we bring 500+ projects, including work for Fortune 500 companies, to rescues like this. We start with the data, fix what is most likely to hurt you next, and leave your team in control. See our services for how engagements are structured.