# Stabilizing a crashing Danish sports-news network

> Five sites on one WordPress install, more than two million visits a month. They crashed every time the national team played, and the previous agency had spent months treating it as a hosting problem. I took over the work, found what was actually causing it, and migrated the network to Kinsta.

**Sports media · 5 sites · WordPress → Kinsta · Solo build**

## Before → After

Before: Down on every Denmark match, and the owner had no direct access to his own servers.

- **0**: match-day crashes after the move
- **0.13s**: average response · Feb 2026
- **4.3M**: requests in 10 days
- **Owns it**: his own code and hosting

## The stakes

Every time Denmark played, the sites went down. Visitors waited five or six seconds for a page to load, the writers couldn't publish, and the traffic went to other outlets at the moment it mattered most. This happened during every game of the Men's EHF EURO 2026. The previous agency had been treating it as a hosting problem for months.

## The insight

**The crashes weren't the servers. They were in the code.**

Three things in the theme were wiping the entire page cache every five minutes. One was the "most popular news" widget, which regenerated on a timer and cleared the whole cache each time it ran. So almost nothing stayed cached, and the server built most pages from scratch on every visit. On a normal day that was just slow. On a match day, with about two thousand people arriving at once, it ran out of capacity and went down. A bigger server would only have delayed the next crash.

## What I did

I moved the codebase off the agency's servers and into the client's own GitHub, so they owned it from then on. I changed how the caching worked so pages could actually stay cached, took out the plugins and extra code that were loading the server for no reason, and added a missing database index. Then I migrated the network to Kinsta, scheduled for a low-traffic window ahead of the tournament's closing weekend, with the editors kept in the loop and nothing lost.

## The result

The match-day crashes stopped, and the sites stayed up for the rest of the championship. In the first ten days they served 4.3 million requests, at an average response time around 0.13 seconds and no thread saturation. During matches, single articles were read 16,000 to 35,000 times. The client also came out of it owning both the code and the hosting, and could close the contract with the previous agency.

**What this proves:** Most problems like this are in the code, not the hardware. The real work is finding where, and fixing it without breaking what's around it.

Dealing with something similar? Let's talk it through. Book a call: https://calendly.com/nerijus-masikonis/30min