IRS "Where's My Refund?" went down during peak filing season — what every team can learn

On 18 February 2026, the IRS “Where’s My Refund?” tracker went dark in the middle of filing season. The site showed a maintenance message while hundreds of users on Downdetector were trying to check their refund status, weeks before the 15 April filing deadline.

The IRS did not publish a detailed postmortem. The official reason was maintenance. It disclosed no load-related root cause.

The timing still says a lot. February is peak filing season, and refund-season traffic on government tax sites follows the same calendar every year. Maintenance work, capacity strain, or both could have caused the outage. The lesson does not change: schedule even planned maintenance around load-tested seasonal peaks.

What happened

On the morning of 18 February 2026, users who opened the IRS “Where’s My Refund?” portal found it unavailable, with a maintenance notice in its place. Downdetector reports passed 300 by midday, mostly from users trying to check their refund status. The outage came roughly eight weeks before the April 2026 filing deadline, in one of the site’s busiest periods of the year.

The timeline

• Morning of 18 February 2026: IRS “Where’s My Refund?” becomes unavailable and shows a maintenance message.
• Downdetector reports climb: over 300 reports by midday, mostly from web users.
• No official postmortem: the IRS cited maintenance and released nothing more on timing, cause, or duration.
• Context: filing season was in full swing, and taxpayers were checking on refunds they had filed in January and early February.

Why it happened

Officially: maintenance. That is the whole public record on root cause.

The context adds this. The IRS refund tracker has a well-known seasonal traffic pattern. Every year, as filing season opens and early returns get processed, millions of taxpayers check their refund status again and again. The February–March window is the busiest period for that flow every year, and reporting describes the outage as coinciding with a refund surge.

The maintenance may have been capacity-related, unrelated infrastructure work, or bad timing. Either way, a critical government service was down during its busiest window. Any team running a system with a known seasonal peak carries the same risk: maintenance scheduled without load-test data can turn planned downtime into an unplanned, high-impact outage.

The failure pattern

This is a seasonal demand spike: a predictable traffic pattern tied to the calendar. The IRS refund tracker is an extreme case because the demand curve is public. Anyone can read the US tax calendar and see that February through early April is the peak.

For any system with a predictable seasonal peak, concurrency will spike. What matters is whether the team knows the system’s capacity at that level and has confirmed it before the season starts. Pick maintenance windows using that knowledge.

How it could have been prevented

Set a seasonal concurrency baseline. Before filing season opens, run a spike test against the refund-tracker path at the expected concurrent user count. Find out what the system sustains at peak and what the p95 response time is.

Keep the peak window free of maintenance. Once you know the seasonal traffic curve, treat the peak as a change freeze, or at least as a high-risk maintenance window. Push non-urgent maintenance to the off-season.

If maintenance has to happen during peak, test failover. If you must update a dependency during filing season, load test the failover path first. Confirm that the maintenance procedure, rollback included, finishes within the outage time users would tolerate.

Pre-scale before the season opens. Do not wait for traffic to show you a capacity gap. Scale up origin capacity, database connection pools, and caching layers before the first day of peak season, and run a load test to confirm the scaled-up setup handles the expected concurrency.

How to test for this with MaxoPerf

Use a spike test that models the refund-season concurrency pattern, and run it well before the season starts.

Engine: k6 or Taurus, closed-model concurrency.

Profile:

• Baseline: 200 virtual users (steady off-season traffic)
• Ramp to peak seasonal concurrency over 5 minutes (the morning filing rush)
• Hold at peak for 20–30 minutes (sustained mid-morning demand)
• Ramp down over 5 minutes

Set peak VUs to your historical or projected seasonal user count for the refund-status path. Do not use total site traffic: this flow puts its demand on a single endpoint.

Target: your staging environment, behind the same load balancer, caching, and auth configuration as production. Test the refund-lookup path end to end.

Execution locations: MaxoPerf managed regions. For a government site with US-based users, use several US regions to model demand spread across the country.

Signals to watch in results:

• Requests per second during the peak hold. Check whether throughput levels off at a safe level or collapses.
• HTTP 5xx error rate. Aim for zero at expected peak.
• p95 and p99 latency for the refund-status lookup response.
• Response time with a simulated maintenance dependency. Run a second test with one backend node offline to check failover behaviour.

When to run: at least 4–6 weeks before peak season opens. That leaves time to find gaps, make changes, and test again. One run a week before the season beats no run, but leaves little room to act on what you find.

Key takeaways

• Plan maintenance windows and seasonal traffic peaks together. A maintenance notice in your busiest week is the worst experience you can give users.
• A load test of the seasonal concurrency baseline, run before the season opens, is what lets you schedule with real data.
• For government and tax services, the traffic calendar is public. A capacity surprise in February has no excuse.
• Even if load had nothing to do with this outage, a documented load test result gives operations, engineering, and leadership one shared baseline for safe maintenance decisions.

Planning around a predictable peak only requires knowing what that peak looks like at the system level. The spike test guide and the load failures series show how to build that baseline.