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

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

The formal cause of the February outages was not publicly disclosed by the banks involved. 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.

This is a medium-confidence incident: the clustering at payday is documented, but a confirmed load or dependency root cause was not released. The lesson stands regardless.

What happened

On 28 February 2025, multiple major UK banking apps failed simultaneously. Lloyds, Halifax, TSB, Nationwide, and Bank of Scotland all experienced outages. Users reported being unable to log in, check balances, or complete transfers — on payday, when the demand to do all three is at its highest point of the month.

The ITV report documented the breadth of institutions affected. The Register’s coverage noted the coincidence of timing and highlighted the shared third-party dependency theory. Computer Weekly placed the incident in the context of 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

No formal root cause was published. The pattern — multiple institutions failing at the same moment, on the same day of the month — is consistent with either a shared third-party dependency failure or a sector-wide capacity event at peak demand. Experts quoted in reporting pointed to third-party concentration as the most plausible explanation.

Month-end is the predictable peak: payroll deposits arrive, customers log in simultaneously to check balances, and payment volumes spike. Any shared infrastructure that processes UK banking transactions at month-end is under its single 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 reveals itself.

The Barclays outage a month earlier, also at payday, adds to the pattern — though the specific cause of that event was also not disclosed in detail.

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, but the risk is compounded by a dependency chain that may not be visible to any individual institution’s engineering team.

The generalisation for any team: if your service depends on shared infrastructure that you do not directly control, you need to test your service’s behaviour when that dependency is under stress — not just whether your own code is correct. And if your traffic has a known monthly peak, that peak must appear in your load testing calendar.

How it could have been prevented

Test at month-end peak concurrency, not 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 that 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 your full dependency chain — not just your own endpoints. Identify where the chain breaks under concurrent load.

Define and track your error budget. If your monthly error budget is consumed in a single payday event, you have a structural capacity or resilience problem, not a one-off incident. Tracking error budget burn rate around month-end events makes this visible before it becomes a regulatory conversation.

Treat month-end as a change freeze. High-risk changes should not be deployed in the week before month-end. If a shared dependency receives a change before the payday window, that change should be load tested at payday-scale concurrency in staging before it ships.

Establish shared-dependency SLOs and circuit breakers. If a third-party dependency starts returning errors, your service should detect it, activate a circuit breaker, and surface a clear degraded-service message to users — not silently fail 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, targeting 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 rather than cascading to a full outage

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

Execution locations: MaxoPerf managed UK/EU regions, or private/BYOC runners if your staging environment requires internal network access. Geographic location of load generation 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 activate 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 there is time to act on any findings. A clean test run close to month-end with no time to fix issues is no better than no test at all.

Key takeaways

• Month-end payday is a predictable, calendar-anchored peak — it belongs on your load testing schedule the same way tax day does.
• When multiple institutions fail simultaneously, a shared dependency is the most likely explanation — test your dependency chain, not just your own service.
• Tracking error budget burn rate around month-end events turns a recurring incident pattern into a visible metric that engineering and leadership can act on.
• Change freezes around high-risk windows are a policy choice that requires load data to enforce with confidence — you need to know what “normal” payday concurrency looks like before you can argue that a change is too risky to deploy before it.
• Formal root cause or not, 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 includes additional examples of seasonal and dependency-driven failures across sectors.