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 mid-filing season. The site returned a maintenance message at a moment when hundreds of users on Downdetector were actively trying to check their refund status, weeks before the 15 April filing deadline.

The IRS did not publish a detailed postmortem. The officially stated reason was maintenance. No confirmed load-related root cause was disclosed.

But the timing tells a clear story: February is peak filing season. Refund-season concurrency on government tax sites is not a surprise — it follows the same calendar every year. Whether the outage was triggered by maintenance work, capacity strain, or a combination of both, the lesson is the same: even planned maintenance must be scheduled around load-tested seasonal peaks.

What happened

On the morning of 18 February 2026, users visiting the IRS “Where’s My Refund?” portal found the site unavailable, displaying a maintenance notice. Reports on Downdetector climbed to over 300 by midday, concentrated among users trying to check their refund status. The outage occurred roughly eight weeks before the April 2026 filing deadline, during one of the highest-traffic periods of the year for the site.

The timeline

• Morning of 18 February 2026: IRS “Where’s My Refund?” becomes unavailable; maintenance message displayed.
• Downdetector reports climb: Over 300 reports by midday, predominantly web users.
• No official postmortem published: IRS cited maintenance; no further detail on timing, cause, or duration was publicly released.
• Context: Filing season was in full swing, with taxpayers actively checking refund timelines for refunds filed in January and early February.

Why it happened

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

What the context adds: the IRS refund tracker carries a well-understood seasonal concurrency pattern. Every year, as filing season opens and early returns are processed, millions of taxpayers check refund status repeatedly. The February–March window is consistently the highest-traffic period for that specific flow, and reporting describes it as coinciding with a refund surge.

Whether the maintenance was capacity-related, unrelated infrastructure work, or a coincidence of timing, the effect was the same: a critical government service was unavailable during its highest-demand window. Any team operating a system with a known seasonal peak faces the same risk — maintenance scheduled without load-testing context can turn a planned downtime into an unplanned high-impact event.

The failure pattern

This is a seasonal demand spike: a predictable, calendar-anchored traffic pattern. The IRS refund tracker is an extreme example because the demand curve is public knowledge — anyone can look at the US tax calendar and identify February through early April as the peak window.

For any system with a predictable seasonal peak, the question is not whether concurrency will spike — it is whether the team knows the capacity at that concurrency level and has validated it before the season begins. Maintenance windows must be chosen with that knowledge, not in spite of it.

How it could have been prevented

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

Block out the peak window for maintenance-free operation. Once you know the seasonal traffic curve, treat the peak window as a change freeze or at least a high-risk maintenance window. Non-urgent maintenance should be deferred to the off-season.

If maintenance cannot be avoided during peak, validate failover. If a dependency must be updated during filing season, run a load test against the failover path first. Confirm that the maintenance procedure — including rollback — can be completed faster than a user-visible outage would be tolerated.

Pre-scale before the season opens. Do not wait for traffic to arrive to discover a capacity gap. Pre-scale origin capacity, database connection pools, and caching layers before the first day of peak season, and verify through a load test that the pre-scaled configuration handles expected concurrency.

How to test for this with MaxoPerf

The right test type is a spike test that models the refund-season concurrency pattern, run well before the season begins.

Engine: k6 or Taurus, closed-model concurrency.

Profile:

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

Set peak VUs to match your historical or projected seasonal user count for the refund-status path specifically — not aggregate site traffic, since this flow concentrates 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 multiple US regions to model geographically distributed demand.

Signals to watch in results:

• Requests per second at peak hold — does throughput plateau at a safe level or collapse under load?
• HTTP 5xx error rate — target zero under expected peak
• p95 and p99 latency for the refund-status lookup response
• Response time under a simulated maintenance dependency (run a second test with one backend node taken offline to validate failover behaviour)

When to run: at least 4–6 weeks before peak season opens. This gives time to identify gaps, make changes, and re-test. A single test run one week before the season is better than nothing, but leaves little room to act on findings.

Key takeaways

• Maintenance windows and seasonal traffic peaks must be co-planned — a maintenance notice displayed during your busiest week is the worst possible user experience.
• Load testing the seasonal concurrency baseline before the season opens is the mechanism that makes informed scheduling possible.
• For government and tax services specifically, the traffic calendar is public: there is no justification for a capacity surprise in February.
• Even if this outage was unrelated to load, a documented load test result creates the shared baseline that operations, engineering, and leadership all need to make safe maintenance decisions.

Planning around a predictable peak is not complicated — it requires knowing what the peak looks like at the system level. The spike test guide and the load failures series walk through how to build that baseline.