I was applying for an EIN on the IRS website yesterday. Internet went out mid-session. When I opened my laptop back up and refreshed, the page loaded — but instead of a real title, it just said `header.title` in giant text.
Not "Apply for an Employer Identification Number." Not "Session Expired." Just the raw template variable, sitting there like the site gave up.
The URL had already redirected to `serviceUnavailable`, so the server knew something was wrong. But the error page itself failed to render correctly. The i18n strings — the text that's supposed to get injected into the template — never loaded. So I got the skeleton without the content.
What actually happened
This is a classic server-side rendering failure. The IRS EIN application is a Java-based web app. When my session expired and the server tried to redirect me to an error page, it couldn't resolve the localization keys. Instead of showing a fallback message, it showed the raw key name.
It's the kind of bug that happens when error pages aren't tested as thoroughly as the happy path. Someone built the service unavailable page, wired up the template variables, and probably tested it once. But they didn't test what happens when the localization service itself is unavailable — or when the session state needed to resolve those keys is already gone.
Why this matters
This isn't really about the IRS. Every team ships bugs like this. I've shipped them. The pattern is always the same: the error handling code gets less attention than the feature code, because by definition it only runs when something is already going wrong.
The fix is straightforward but tedious. Every template variable needs a hardcoded fallback. Every error page should be static HTML that doesn't depend on the same services that might be failing. If your error page can fail, you don't have an error page — you have two problems.
The real takeaway
Test your error states with the same energy you test your features. Kill the session mid-flow. Pull the network cable. Let the database connection timeout. If your app can't fail gracefully under those conditions, it will eventually fail ungracefully in front of a real user.
In this case, that real user was me, staring at `header.title` on a government website while trying to get a tax ID. It's tax season — keep an eye out for stuff like this if you're doing anything on IRS.gov right now. Their systems are under peak load and the cracks show.
The best error page is boring. It loads fast, it says what happened in plain language, and it tells you what to do next. It doesn't depend on JavaScript, API calls, or session state. It just works — even when nothing else does.