It's November 4 and the county's election page went down last night. What happened?

Imagine the morning after

Here's the exercise. It's Wednesday, November 4, 2026. The general election was yesterday. In a mid-sized county we've made up for this note, the county website was slow from about 7:30 in the evening and stopped loading at all for a stretch after 8. People refreshed. Local reporters posted screenshots of the error page. The phones at the elections office rang until midnight, mostly with one question: is the count broken?

It wasn't. The count was fine. The website wasn't.

That's the point of a pre-mortem. You imagine the failure as if it already happened, then work backwards to the reasons. It's much easier to find causes when you aren't defending a plan. Two weeks out, it's also the right size of exercise: big enough to find real problems, small enough to fix them.

So, in our imaginary county, what went wrong?

Reason one: every visit asked the database

The results page was built years ago as a page that looks up the latest numbers every time someone opens it. On an ordinary day that's elegant. On election night, every refresh from every resident was a fresh question to the same database, which was also running the rest of the county's site.

The fix isn't a new system. It's serving a copy. Publish results as a plain page that's regenerated when new numbers arrive, and let a cache or a content delivery service hand that copy to everyone. Thousands of people reading the same page should cost about the same as one.

Check, too, which parts you actually own. In many places the official results come from the state or an elections vendor, and the county site links to them or embeds them. If that's you, know exactly where your page ends and theirs begins, and make sure your page still loads when theirs is slow.

Reason two: the polling-place lookup shared the server

Earlier in the day, the polling-place lookup had its own rush. It's a heavier tool: an address goes in, a search runs, a map loads. In our composite county it lived on the same server as everything else, so the morning rush slowed the whole site, and the evening rush for results landed on a server that was already tired.

Separate the heavy tools from the pages people only read. If an outside vendor runs the lookup, ask them this week how it behaves under a rush and what they'll show if it slows down. A one-line answer is fine. No answer is the answer you need to plan around. If the lookup can't be moved, put a plain fallback next to it: a downloadable list of polling places by precinct, and the phone number to call. If the clever tool struggles, people still get an answer.

This is the same instinct as deciding what still works when you switch it all off. Pick the page that must survive, and make it simple enough to survive.

Reason three: the link everyone shared pointed somewhere else

At 9 p.m., someone in the communications office posted a link to the results on social media. It was last cycle's address. Half the shares went to an old page that said results "will be posted here," and people assumed nothing was happening.

Pick one address for election information now, and make it short and stable: something like the county site plus /election. Put a clear "last updated" time at the top of the results page, in local time, and update it with every upload, even if no numbers changed. Redirect every old election address you can find to the new one. Give the same address to the local paper, the radio station and the library, so the link that travels is the one you chose.

Reasons four and five: nobody had practiced, and nobody owned the message

The numbers reached the website by hand. A staff member exported a file, renamed it, and uploaded it through the content system. At 10 p.m., with a dozen people watching, the upload form timed out on the larger file, and the person who knew the workaround had gone home.

Write the upload down as steps, and rehearse it twice with a test file the same size as the real one. Name two people who can do it, and make sure both have access that night. Decide in advance what goes on the page if an upload fails: a short note with the time of the last good update.

Two weeks out, the best change is the one you can rehearse twice.

Then the second failure. When the site slowed down, three different people posted three different updates, and the phone line said nothing about the website at all.

Agree, now, who says what and where. One person posts website status. One short message is ready to go: the results page is slow, here's the backup address, here's when the next update will be. The phone greeting gets a line about where to find results. Our note on status that tells people what they can do applies here too.

Put this into practice before November 3

Run this exact pre-mortem with your web team, your elections staff and whoever posts to social media. Thirty minutes. Ask everyone to finish the sentence, "The site went down because…" Then sort what you hear into fix-now, have-a-fallback, and accept.

For fix-now, the usual short list: serve read-only election pages from a cached or static copy; separate or back up the polling-place lookup; one address, with redirects; a visible "last updated" time; a rehearsed upload with two named people; one owner for status messages.

Don't redesign anything. Don't launch a new results page this cycle. Don't change the content system's settings the week before.

After the election, keep the notes. The same exercise works for the next property tax deadline or snow emergency, and the cloud outage in London this week showed how many public services depend on someone else's servers.

If your public website needs to hold up on its busiest night, or you'd like a calm plan for the next one, that's government and public sector work we do. Talk to us.

Related work: Wellthie.