---
title: "A ground station burned and nothing missed a beat"
date: 2026-08-02
url: https://remiam.co.uk/notes/ground-station-burned-nothing-missed
tags: [Space, Aerospace, Infrastructure]
read_time_minutes: 5
description: "A studio view on the July 2026 wildfire at NASA's Madrid Deep Space Network complex: why the failover worked, and what geographic redundancy means for the systems we build on the ground."
---

# A ground station burned and nothing missed a beat

*Published 2026-08-02 · 5 min read · by Liam (Remiam)*

A wildfire went through NASA's Madrid Deep Space Communications Complex on 24 July. Ninety people evacuated, a 70 metre dish went offline, and spacecraft across the solar system carried on talking. The failover was not clever engineering on the day. It was a decision made sixty years earlier.

On 24 July a wildfire reached the Madrid Deep Space Communications Complex at Robledo de Chavela, about 65 km west of Madrid. All ninety staff were evacuated safely and the fire passed through the site. The complex runs a 70 metre antenna and five 34 metre dishes, and it went off the air. Initial inspection the next day found damage mostly to pavement and surrounding vegetation, with no significant structural damage to the antennas or buildings, according to NASA. ESA's nearby Cebreros station appeared unharmed.

Nothing was lost. NASA shifted the load to Goldstone in California and Canberra in Australia and spacecraft communications continued. That is the part worth sitting with, because it is not really a story about a fire.

## The redundancy was a decision about geography

The Deep Space Network is three complexes placed roughly 120 degrees apart in longitude. Madrid, Goldstone, Canberra. That spacing exists so that any spacecraft, anywhere out there, always has at least one dish with line of sight as the Earth turns. It was designed for rotation, not for wildfires. But because the sites are genuinely far apart, and because each one is independently staffed and powered, losing one to a regional emergency degrades capacity without stopping the service.

That is the useful distinction. The failover did not have to be invented on 24 July. It was a property the system already had, bought decades earlier with concrete and land in three countries, for an entirely different reason.

> Resilience is rarely a feature you add. It is usually a consequence of a decision you made about where things live.

## Most systems fail this test on a much smaller stage

We build installations and operational systems, and the equivalent question comes up on nearly every project. Where does the thing that must not stop actually live. In practice the honest answer is often: one cupboard, on one venue's broadband, behind one router that a cleaner can unplug.

Three sites in three countries is not the lesson to take from this. The lesson is that redundancy has to be structural and boring, not clever and reactive. A retry loop is not redundancy. A queue with nowhere else to drain to is not redundancy. If everything routes through one physical location, then any local event, a flood, a power cut, a road closure, a fire, is a total outage, and no amount of software written afterwards will change that.

## What we actually do about it

- Assume the site loses its connection during the busiest hour. On live installations we run a local database at each venue that keeps working while disconnected and syncs to the cloud when it can, rather than treating the network as a given.
- Separate the sites that can fail together. Two servers in the same rack share a fate. So do two venues on the same street with the same supplier.
- Make the switchover routine, not heroic. If failing over needs a specific person awake and reachable, it will not happen at 3am on a bank holiday.
- Rehearse the loss. Turn a node off deliberately, during the day, with people watching. That is how you learn what quietly depended on it.

## The other half of it

Losing Madrid was not free. Three complexes carrying the traffic of every deep space mission is already a tight schedule, and dropping to two means contention: something gets less time on a dish. The service continued, but the margin shrank. That is what good redundancy actually buys, not immunity, but the room to keep going while you sort the problem out.

Should a client care about a fire at a Spanish antenna field. Directly, no. But the shape of it is the shape of every serious infrastructure decision we make on their behalf. Decide early where things live, accept that the boring answer costs more up front, and be honest that the expensive part is not the failover logic. It is the second location.

## References

1. [SpaceNews, NASA and ESA facilities avoid major damage from wildfires in Spain (2026)](https://spacenews.com/nasa-and-esa-facilities-avoid-major-damage-from-wildfires-in-spain/)
2. [Spaceflight Now, Critical NASA Deep Space ground station in Spain evacuated due to wildfires (2026)](https://spaceflightnow.com/2026/07/24/critical-nasa-deep-space-ground-station-in-spain-evacuated-due-to-wildfires/)
