UK banks payday outages 2025 — when month-end peak meets a fragile shared dependency

Several UK banks (Lloyds, Halifax, TSB, Nationwide, Bank of Scotland) had app and online banking failures on payday Friday, 28 February 2025. Earlier in the year, Barclays had a roughly three-day outage in late January 2025. The clustering was no coincidence. The end of the month is the single highest-volume moment in consumer banking: payroll deposits land, and customers immediately check balances, make transfers, and pay bills.

The banks involved did not publicly disclose the formal cause of the February outages. Industry experts quoted in coverage suspected a shared third-party dependency as a contributing factor. The Financial Conduct Authority had already flagged rising third-party outage risks as a systemic concern across the sector.

Confidence in this incident is medium. The payday clustering is documented, but nobody released a confirmed load or dependency root cause. The lesson holds either way.

What happened

On 28 February 2025, several major UK banking apps failed at the same time. Lloyds, Halifax, TSB, Nationwide, and Bank of Scotland all had outages. Users reported that they could not log in, check balances, or complete transfers, on payday, when demand for all three peaks for the month.

The ITV report documented how many institutions were affected. The Register’s coverage pointed out the shared timing and raised the shared third-party dependency theory. Computer Weekly set the incident against the FCA’s ongoing concerns about third-party concentration risk.

The timeline

• Late January 2025: Barclays experiences an outage lasting approximately three days, also during a payday window.
• 28 February 2025 (Friday, payday): Multiple UK banks experience simultaneous app and online banking failures; users unable to access accounts at peak transaction time.
• Clustering noted: Industry observers note that several institutions fail at the same time, raising the shared-dependency question.
• No formal postmortem: None of the banks publicly disclosed a detailed root cause; formal cause remains undisclosed.
• FCA context: The FCA had flagged rising third-party outage risks as a growing concern in the UK banking sector.

Why it happened

Nobody published a formal root cause. Several institutions failed at the same moment on the same day of the month. That pattern fits either a shared third-party dependency failure or a sector-wide capacity event at peak demand. Experts quoted in reporting named third-party concentration as the most plausible explanation.

Month-end is the predictable peak. Payroll deposits arrive, customers log in at once to check balances, and payment volumes spike. Any shared infrastructure that processes UK banking transactions carries its highest load of the month at exactly this moment. If that infrastructure has a capacity ceiling, a configuration limit, or a dependency of its own that does not scale, month-end is when it shows.

The Barclays outage a month earlier, also at payday, adds to the pattern, though its specific cause was not disclosed in detail either.

The failure pattern

This is a seasonal demand spike with a fragile shared dependency. The month-end payroll peak is as predictable as a tax deadline or an exam results day. The risk grows because the dependency chain may be invisible to any single institution’s engineering team.

The general rule for any team: if your service depends on shared infrastructure you do not control, test how your service behaves when that dependency is under stress, in addition to checking that your own code is correct. And if your traffic has a known monthly peak, put that peak on your load testing calendar.

How it could have been prevented

Test at month-end peak concurrency, not at average traffic. Average daily transaction volumes significantly understate the payday spike. Build a load profile from your historical transaction data for the last Friday of each month and use it as your test target.

Map and test your dependency chain. If your banking app depends on a third-party payment processor, authentication provider, or clearing service, run a spike test that models the payday traffic pattern against the full dependency chain, not only your own endpoints. Find where the chain breaks under concurrent load.

Define and track your error budget. If a single payday event consumes your monthly error budget, you have a structural capacity or resilience problem, not a one-off incident. Tracking the error budget burn rate around month-end shows this before it turns into a regulatory conversation.

Treat month-end as a change freeze. Do not deploy high-risk changes in the week before month-end. If a shared dependency changes before the payday window, load test that change at payday-scale concurrency in staging before it ships.

Set shared-dependency SLOs and circuit breakers. If a third-party dependency starts returning errors, your service should detect it, trip a circuit breaker, and show users a clear degraded-service message. It should not fail silently or generate retry storms.

How to test for this with MaxoPerf

The right test type is a spike test sized to month-end payday concurrency and aimed at your own banking app’s critical paths.

Engine: k6 or Taurus, targeting your login, balance-check, and payment-initiation endpoints.

Profile, payday spike:

• Baseline: 1,000 virtual users (normal mid-month traffic)
• Ramp to payday peak over 2 minutes (model the rapid arrival of payroll recipients)
• Hold at peak for 15–20 minutes (model sustained payday morning demand)
• Ramp down over 5 minutes

Set your peak VU count from your own historical data. If you process a large share of UK payroll, your payday concurrent session count may be 5–15 times your daily average.

Second test, degraded dependency:

• Run the same payday spike profile
• With your third-party dependency stubbed to add 2–4 seconds of latency or return 20% errors
• Verify your service queues gracefully and returns coherent errors instead of cascading into a full outage

Target: your own staging environment, behind the same infrastructure as production. Test the paths users rely on at payday: login, account balance, payment initiation.

Execution locations: MaxoPerf managed UK/EU regions, or private/BYOC runners if your staging environment needs internal network access. Where load is generated matters for regulated financial services.

Signals to watch in results:

• Transaction success rate at payday peak (target: within your error budget)
• p95 and p99 response time for login and payment initiation under peak load
• Error rate onset: at what concurrent user count does your service start returning errors?
• Dependency-degraded scenario: does your circuit breaker trip correctly, and does your error rate stay below the threshold that would breach your error budget?

Schedule the test before each month-end. Run it 2–3 weeks before the last Friday of the month, so you have time to act on the findings. A clean run so close to month-end that you cannot fix anything is no better than no test.

Key takeaways

• Month-end payday is a predictable, calendar-anchored peak. Put it on your load testing schedule the same way you put tax day.
• When several institutions fail at once, a shared dependency is the most likely explanation. Test your dependency chain as well as your own service.
• Tracking error budget burn rate around month-end turns a recurring incident pattern into a visible metric that engineering and leadership can act on.
• A change freeze around high-risk windows is a policy choice, and you need load data to enforce it with confidence. You have to know what “normal” payday concurrency looks like before you can argue that a change is too risky to deploy ahead of it.
• With or without a formal root cause, the lesson is the same: if you have a predictable peak, test at that peak before it tests you.

The spike test guide covers the test design in detail. The load failures series has more examples of seasonal and dependency-driven failures across sectors.