A bad update usually takes two to four weeks to fix, but the timeline depends on how many people it breaks and how visible the problem is

When a software update causes widespread problems — crashes, data loss, or broken features — the company's response time depends on severity and how many users are affected. A critical bug that makes the software unusable for most people gets a hotfix within days. A problem that only affects a specific hardware setup or workflow might take weeks to diagnose and patch, or the company might decide the fix isn't worth the resources and roll back the update instead.

The clock starts when the company becomes aware of the problem, not when you first experience it. If you're among the first to install a bad update, you might wait days before the company even knows something is wrong. If millions of people hit the same issue at once, the company usually knows within hours.

Key Takeaways

  • Critical bugs that break core functions typically get a hotfix within 24 to 72 hours; less severe problems take two to four weeks or longer.
  • The company must first reproduce the problem in their own testing environment before they can write a fix, which adds days to the timeline.
  • Some bad updates are rolled back entirely rather than fixed, which is faster but means you lose any features the update was supposed to add.
  • You can usually delay or refuse a bad update on Windows, Mac, and Linux, but mobile operating systems often force updates automatically.
  • The company's awareness of the problem depends on user reports, crash data, and social media — if few people report it, the timeline stretches.

Why the first few days are silent

When a bad update rolls out, the company doesn't when ready know it's broken. They released it because their own testing passed. The first sign usually comes from user reports on social media, support forums, or automated crash reporting that the company monitors.

On Windows, Microsoft collects crash data automatically if you have telemetry enabled. On Mac, Apple does the same. On Linux, the distribution maintainer relies on user reports in bug trackers. Mobile operating systems like iOS and Android also collect crash data, but the lag between a crash happening and the company seeing the pattern can be 12 to 24 hours.

If the problem only affects a small percentage of users — say, people with a specific graphics card or a particular version of another program installed — the company might not notice for days. The more people affected, the faster the pattern becomes obvious.

Reproduction and diagnosis take the longest

Once the company knows something is broken, they have to make it happen in their own lab. This is harder than it sounds. A user might report "my email won't open," but the company needs to know: on what operating system version, with what hardware, after doing what steps, with what other software installed. If the report is vague, the company's engineers might spend days trying to recreate the problem before they can fix it.

Some bugs are straightforward to reproduce — the update breaks something obvious that fails the same way for everyone. Other bugs are intermittent or only happen under specific conditions. A memory leak that causes a crash after 12 hours of use takes longer to diagnose than a crash that happens when ready when you open the program.

Once the engineers understand what's broken, they still have to write the fix, test it on multiple configurations, and make sure the fix doesn't introduce new problems. That process alone takes days for a straightforward bug and weeks for something complex.

Hotfixes arrive faster than regular updates

A hotfix is a small patch released outside the normal update schedule, specifically to address a critical problem. Microsoft, Apple, and major Linux distributions all have hotfix processes. A hotfix skips some of the normal testing because the alternative — leaving the broken update in place — is worse.

Critical bugs get hotfixes within 24 to 72 hours. "Critical" means the software is unusable for most people, or data is being lost. A crash that happens only when you use a specific feature, or a performance problem, or a cosmetic bug usually doesn't may have access to.

Hotfixes are smaller and faster to deploy than regular updates because they change only the code that's broken. A regular update might include dozens of changes; a hotfix might change one function. That means less testing is needed, and the fix can roll out faster.

Rollbacks are faster than fixes but come with a cost

Sometimes the company decides it's faster to pull the bad update entirely than to fix it. This is called a rollback. Microsoft has rolled back Windows updates within hours of release. Apple has done the same with macOS and iOS updates. When a rollback happens, users who installed the update are reverted to the previous version.

A rollback can happen in 6 to 24 hours because the company doesn't have to diagnose the problem — they just have to stop distributing the broken version and push the old one back out. The downside is that any features or security fixes in the bad update are also rolled back. The company then has to fix the problem and re-release the update, which adds another two to four weeks.

Rollbacks are rare because they're disruptive and they undo security patches. A company will usually only rollback if the update is breaking the software for a large percentage of users or causing data loss.

Mobile updates are harder to stop once they start

On iPhone and iPad, Apple pushes updates to all devices and you cannot delay them indefinitely. Once you see the update notification, you have a few days before it installs automatically. If the update is bad, you're stuck with it until Apple releases a fix.

On Android, the timeline varies by manufacturer. Some Android phones allow you to delay updates; others push them automatically like Apple does. Google's own Pixel phones can be delayed for a few weeks, but eventually the update installs whether you want it or not.

On Windows and Mac, you have more control. You can delay updates for weeks or months, though security updates eventually become mandatory. On Linux, you control when updates happen — you can wait indefinitely if you choose.

What you can do while waiting for a fix

If you're stuck with a bad update on a device you can't roll back, your options are limited. You can uninstall the update if your operating system allows it — Windows and some Android phones let you do this. You can avoid the broken feature until the fix arrives. You can use a different device or program temporarily.

On Windows, you can use Settings > System > Recovery > Go back to get the previous version, but only for a limited time after the update — usually 10 days. After that, the old version is deleted and you're committed to the new one.

On Mac, you can use Time Machine to restore from a backup made before the update, but only if you have a backup. You cannot easily downgrade macOS without erasing and reinstalling.

On iPhone and iPad, you cannot downgrade to a previous version once you update. Your only option is to wait for the fix.

Frequently Asked Questions

How do I know if an update is bad before I install it?

Check social media, Reddit, and the company's support forums for reports of problems. If thousands of people are reporting the same crash or data loss within hours of the update's release, it's safe to assume it's bad. Wait a few days before updating if you see widespread complaints.

Can I refuse to install a bad update?

On Windows and Mac, yes — you can delay updates for weeks. On iPhone, iPad, and many Android phones, no — the update will eventually install automatically. On Linux, you control updates entirely and can refuse them indefinitely, though security updates are recommended.

What if the company never fixes the bad update?

This is rare but happens. If the problem is minor or affects very few people, the company might decide the fix isn't worth the cost and leave it broken. Your options are to work around the problem, downgrade if possible, or switch to a different program or device.

Why does the company release bad updates in the first place?

Testing cannot catch every combination of hardware, software, and user behavior. A change that works fine in the company's lab might break on your specific setup. The company balances the risk of releasing untested code against the cost of delaying a release — sometimes they get it wrong.

Is it safe to install an update that's been out for a week?

Generally yes. If a major problem existed, reports would surface within 24 to 48 hours and the company would either hotfix it or roll it back. Waiting a week gives you time to see if widespread complaints emerge, and it's a reasonable safety margin for most users.