The Cloud Keeps Breaking. So Why Are Tech Workers Still Being Laid Off?

CrowdStrike, AWS, Azure, Cloudflare and Google Cloud have reminded us how dependent everyday life is on technology. So why does the job market for the people who keep it working feel so unforgiving?

I was delivering Uber Eats orders in Sydney when the CrowdStrike outage spread across the world on 19 July 2024.

I had spent years working with cloud infrastructure, websites, operating systems and technical support. Yet there I was, on the other side of the counter, experiencing the consequences of technology through food delivery rather than an incident queue.

Around that time, I remember seeing KFC's systems stuck in a Windows blue-screen boot loop. My recollection places that sighting on the day before the widespread CrowdStrike incident, which means I cannot reasonably claim that CrowdStrike caused those particular crashes. But the image stayed with me: a familiar failure from the IT world, appearing in an ordinary restaurant where people were trying to serve customers and get through their shifts.

When the much bigger outage hit, I wondered whether employers would start taking infrastructure reliability — and the people responsible for it — more seriously.

More than two years later, I still do not feel that the tech job market has recovered in the way I expected. And the incidents have hardly stopped making headlines: Google Cloud, AWS, Azure and Cloudflare have each experienced serious disruptions since then.

At the same time, companies have continued restructuring and announcing layoffs. Borrowing costs have changed the economics of growth, and AI has given executives a new reason to ask whether the same work can be done by smaller teams.

That is the paradox I want to examine: technology can become more essential to society while the market for technical labour becomes more difficult.

The world did not literally go offline — but it felt that way

The CrowdStrike incident came from a faulty configuration update to its Falcon sensor, causing affected Windows machines to crash. It was not a Microsoft Windows update, although Windows was the operating system on which the affected software ran. CrowdStrike's technical account explains the mechanism.

Microsoft estimated that around 8.5 million Windows devices, fewer than 1% of all Windows machines, were affected.

That is a much smaller proportion than the impression of an entire world going down. But percentages are deceptive when the affected devices sit inside airports, hospitals, retail operations and other services people need. A small proportion of machines can be positioned at a very large proportion of consequential points of failure.

The recovery also revealed the amount of human work behind supposedly automated infrastructure. Microsoft said it deployed hundreds of engineers and experts to help affected customers. There were people diagnosing, recovering and checking machines while frontline staff and customers dealt with the consequences.

To me, the interesting part was not simply that software broke. Software has always broken. It was how a trusted component deployed across many organisations could create such a wide operational problem so quickly.

And it left an uncomfortable question: if the need for skilled technical people becomes obvious during an incident, why does that not necessarily translate into sustained hiring afterwards?

Then came the cloud and network outages

CrowdStrike was an endpoint-security software failure, not a cloud-platform outage. The subsequent incidents were different in both cause and geographic scope. They are still useful to consider together because each shows how much other technology can depend on one shared service or control mechanism.

Here are several major incidents from the period after CrowdStrike:

• 13 June 2025, Sydney time — Google Cloud: an issue involving Service Control and a policy update caused widespread API errors across numerous Google Cloud products and regions. Google's incident report.
• 20–21 October 2025, Sydney time — AWS: an issue in DNS automation for DynamoDB in the Northern Virginia (us-east-1) region affected dependent AWS services and applications, with consequences extending beyond that region for some customers. AWS's incident summary.
• 30 October 2025, Sydney time — Microsoft Azure: a configuration problem in Azure Front Door and CDN affected the global edge delivery service, disrupting customer applications and other Microsoft services. Microsoft's post-incident review.
• 18–19 November 2025, Sydney time — Cloudflare: a database permissions change ultimately resulted in a problematic Bot Management configuration file and widespread traffic failures. Cloudflare's postmortem.
• 5 December 2025 — Cloudflare again: a separate software change during work related to vulnerability mitigation caused a roughly 25-minute incident; affected customers accounted for about 28% of Cloudflare's HTTP traffic. Cloudflare's postmortem.
• 20 October 2026, Sydney time — Google Cloud London: an external power failure, combined with a failed automatic generator start, affected the europe-west2-b zone and caused disruption elsewhere in the London region. Google reported six hours and eight minutes of primary impact, not a global Google Cloud failure. Google's final incident report.

Not every one of these was global. Nor does a list of memorable incidents prove that the rate of worldwide cloud outages is increasing year on year. Establishing that would require consistent incident definitions, comparable reporting and a reliable denominator for the growing amount of infrastructure in use.

What I can say is that high-impact failures keep confronting users and engineers with the same issue: a distributed system can still have a central point of failure. Identity, DNS, policy distribution, configuration management and deployment pipelines can become common dependencies, even when the servers themselves are spread across regions.

Large platforms offer extraordinary capabilities. They also allow an error in shared machinery to propagate much further than it would inside one small application.

Meanwhile, the Australian IT hiring numbers tell another story

My impression of a difficult job market is personal. It needs evidence beyond my own applications.

In June 2025, SEEK reported that Australian Information & Communication Technology job advertisements were 10.5% lower than a year earlier and had fallen to the lowest level in its series at that time.

The picture in a September 2026 Jobs and Skills Australia analysis is more striking:

• Only 32% of surveyed employers in the Computer System Design and Related Services industry were recruiting in 2025–26, compared with 49% across all industries.
• Just 16% of employers in that IT industry expected to increase staffing during the following three months.
• Online advertisements for ICT Professionals had fallen to 5,960 in July 2026, down from a recent high of 14,780 in April 2022, using Jobs and Skills Australia's trend series.

Those are different measures covering different groups. A job advertisement is not an employee, and a recruitment survey is not a census of every company. Still, they help explain why an experienced applicant can feel as though opportunities are scarcer and competition is higher.

There is an important counterpoint in the same report: employment in Computer System Design and Related Services grew 5.2% in the year to February 2026. Industry employment can rise even as new vacancies and recruitment activity weaken. Not every technology occupation or employer is shrinking.

That distinction matters. I am not arguing that every tech job is disappearing. I am asking why obvious infrastructure needs can coexist with mass layoff announcements, constrained recruitment and a much tougher search for the next position.

Why a serious outage does not automatically mean more jobs

When an essential system fails, organisations suddenly need incident responders, systems administrators, network specialists, security analysts, support teams, platform engineers and people who understand the affected business process.

But emergency demand is not the same thing as a permanent staffing decision.

A company might fix the immediate problem through its existing staff, vendor support, a temporary contract or a software change. It might migrate a workload, adopt a managed service or consolidate another platform. Some of those choices improve reliability. None necessarily creates a permanent position with the same title in the same location.

Cloud computing itself changes where technical labour sits. Moving from self-managed servers to SaaS can remove work from one company's internal team while transferring responsibility to a vendor. The work has not vanished, but it may be performed by fewer people at greater scale, in another country, or under a different contract.

There is also an accounting problem. A new product feature has a launch date and an identifiable business case. An outage that didn't happen is harder to show on a dashboard. Preventive maintenance, tested backups, patching and disaster recovery can look like costs until the day they prove their value.

I have worked in cloud and website operations long enough to appreciate how much time can disappear into diagnosing issues, restoring services and keeping older systems compatible. None of that work becomes unnecessary because a sales presentation says the cloud is fully managed.

The organisation still has to know which services it depends on, how to recover them and who is responsible when a third party fails.

The interest-rate cycle changed the economics of hiring

It is tempting to connect every layoff to AI, but the financial environment changed before today's AI boom reached its current scale.

During the low-rate years, cheap financing encouraged growth and allowed some firms to invest ahead of revenue. Rising interest rates made future earnings less valuable in present terms and increased the cost of financing. Companies and investors placed more emphasis on immediate cash flow, margins and efficiency. The effects differed substantially between heavily funded startups, profitable established firms and public-sector employers.

Australia's cash-rate history is a useful reminder that the trend has not been a simple, uninterrupted increase every year. The RBA tightened rapidly through 2022–23, then cut the cash rate in February 2025. By 29 September 2026, it had raised the target again to 4.60% amid renewed inflation concerns.

That does not mean Australian cash-rate decisions directly caused a particular US technology layoff. Global firms face different borrowing markets, profitability pressures and business strategies. My point is that the cost of capital and expectations for returns help shape whether management approves another engineering role, even when the technical need is real.

The business can become more dependent on software at the very moment its finance team becomes less willing to expand headcount.

AI has added another calculation — and a lot of uncertainty

Advancing AI capabilities have changed the conversation again. An engineer can now use AI to summarise logs, draft code, suggest tests, explore documentation or speed up routine troubleshooting. Some of those gains are real.

Executives can also look at those capabilities and ask whether a smaller team should deliver the same output. Companies have announced restructuring and job reductions alongside shifts towards AI investment, as Reuters documented in October 2026.

However, it is a mistake to treat every AI-related layoff announcement as proof that software replaced the employees concerned. Cost-cutting, earlier over-hiring, product changes, offshoring, organisational restructuring and AI investment can overlap. A company may reduce employment in anticipation of productivity gains that have not yet been demonstrated.

The Australian evidence remains more cautious. The Department of Employment and Workplace Relations' July 2026 report found no evidence to date of broad AI-driven labour-market upheaval. It did find slower growth in occupations more exposed to potential generative-AI automation, but described that signal as suggestive rather than proof of widespread displacement.

Meanwhile, AI skills are becoming more prominent in recruitment. SEEK's September 2026 data showed AI-related skills mentioned in 14.9% of ICT job advertisements and a substantial year-on-year increase in advertisements mentioning those skills.

I see two things happening at once. Employers increasingly want workers who can use AI effectively, while some are also considering how much headcount they need in an AI-assisted organisation. Neither trend removes the need for sound engineering judgement.

An AI assistant might suggest why a service is returning errors. It does not, by itself, own the recovery objective, decide whether a change is safe for real customers, coordinate a restaurant's fallback process or take responsibility for making sure backups can actually be restored.

If AI helps engineers produce changes faster, organisations may need more discipline around reviewing, testing and deploying those changes, not less. Generating work quickly and operating a dependable service are related but different problems.

The uncomfortable combination: more software, fewer visible maintainers

Put the forces together and a plausible pattern emerges:

A company depends on more interconnected software. Shared infrastructure creates powerful economies of scale but also concentrates certain risks. Economic pressure makes hiring harder to justify. AI raises expectations for productivity. When something fails, a smaller team may be expected to recover the service quickly anyway.

That is a structural concern, not a claim that layoffs caused the CrowdStrike, AWS, Azure, Cloudflare or Google Cloud incidents. The published investigations identify particular technical causes. They do not establish that staffing cuts were responsible.

The risk I worry about is what happens between incidents: whether teams have enough protected time to test restores, simplify dependencies, stage deployments, review permissions and practise the operational decisions they might one day need to make under pressure.

Reliability can deteriorate quietly if those activities are perpetually postponed, even when the people who remain are talented and hardworking.

And there is a deeper mismatch: a company's dependence on technology is not the same thing as its willingness to fund employees. Those two quantities can move in opposite directions for quite a long time.

This is also why I keep returning to the simpler web

My earlier article, PHP2Shell and the Case for a Simpler Web, examined the attack surface and maintenance burden behind ordinary websites. That line of thinking also grew out of security warnings such as the UK's NCSC report on APT28 exploiting routers to hijack DNS. Router compromise, PHP runtime vulnerabilities and cloud outages are separate problems. They nevertheless raise a related design question: how many components must remain trustworthy and operational for a person to complete one simple task?

For a blog post, I increasingly prefer static files over a live CMS, database and collection of plugins needed for every request. A static site cannot prevent an upstream CDN or DNS provider from failing. It can remove application-level dependencies and make the content easier to copy, restore or serve elsewhere.

That is why this site uses Eleventy and Cloudflare Pages. Cloudflare itself has had significant outages, which is a useful reminder not to confuse a simplified application with complete independence from providers.

For an online ordering system, financial platform or healthcare application, the answer will necessarily be more complex. Transactions, identity and real-time information cannot all be replaced with static HTML. But the underlying discipline is the same:

Keep essential operations independent of optional ones, know the failure modes, and make recovery practical for the humans using the system.

Simplification is not an argument for eliminating technical jobs. It is an argument for using engineering time on the things that matter rather than preserving unnecessary maintenance for its own sake.

What I wish organisations would take from all these incidents

There is a better way to connect reliability concerns to employment and engineering decisions.

Fund prevention as real work. Give teams time and ownership to patch, rehearse recovery, examine dependencies and remove fragile configuration. A recovery plan nobody has tested is mostly a theory.

Treat configuration changes like code changes. Several high-profile failures have involved ordinary operational changes rather than a dramatic hardware collapse. Staging, blast-radius limits, observability and rollback matter for policy and control-plane changes too.

Measure recovery, not just deployment speed. Fast releases are useful, but so are verified backups, working fallback processes and the ability to operate when identity, DNS or a cloud region is unavailable.

Be specific about what AI can replace or improve. Productivity claims should be tested against support quality, defect rates, recovery time and customer impact — not merely the number of tickets or lines of code one person can generate.

Keep the people who understand the system involved. Cloud vendors provide valuable infrastructure, but nobody outside a business fully understands what its staff and customers must accomplish when a system is down.

Not every organisation needs a larger engineering department. Some need fewer moving parts. Some need better suppliers. Others need more engineers, stronger support coverage or properly funded on-call work. The sensible answer depends on the actual service and its consequences of failure.

What I remember after the blue screens

I still remember looking at failed restaurant systems while doing Uber Eats, with years of technical experience behind me and an unexpectedly direct view of how technology becomes part of an ordinary working day.

The CrowdStrike outage made the labour behind digital services visible for a moment. Later cloud outages have kept illustrating the reach of shared dependencies. The job market, meanwhile, has been shaped by financial pressures, changing business models and growing expectations of AI.

I do not expect every outage to create a wave of permanent jobs. But I do think organisations should be more careful about treating technical maintenance as expendable while assuming the services it supports will remain dependable.

The world keeps asking more of its digital infrastructure. The question is whether it is willing to invest in the people, time and simpler designs needed to keep that infrastructure working.

Sources and further reading

• CrowdStrike — Falcon content update technical details, July 2024
• Microsoft — Helping customers through the CrowdStrike outage, July 2024
• Google Cloud — June 2025 multi-product incident
• AWS — October 2025 DynamoDB disruption in Northern Virginia
• Microsoft Azure — October 2025 Azure Front Door post-incident review
• Cloudflare — November 2025 outage analysis
• Cloudflare — December 2025 outage analysis
• Google Cloud — October 2026 London region incident report
• SEEK — June 2025 Australian employment report
• Jobs and Skills Australia — Recruitment trends in the IT industry, September 2026
• Reserve Bank of Australia — February 2025 monetary policy decision
• Reserve Bank of Australia — September 2026 monetary policy decision
• Department of Employment and Workplace Relations — AI and employment in Australia, July 2026
• SEEK — September 2026 employment dashboard
• Reuters — Companies cutting jobs as investments shift toward AI, October 2026
• UK NCSC — APT28 exploitation of routers for DNS hijacking
• PHP2Shell and the Case for a Simpler Web — stefs.site