There was certainly a real problem. Not a problem that should have inspired doomsday preppers, but there was a lot of potential for financial losses, a lot of aggravation related to avoiding such financial losses (e.g., explaining that the videotape you return to the store isn't 100 years overdue, and you shouldn't need to pay a $90K late fee), disruption of services (banking, communications, medical), and loss of electrical power supply. The worst-case possibilities included meltdowns of nuclear reactors (unlikely, due to multiple safety systems, but the same can be said about the Chernobyl accident) and nuclear war (due to false positive reports of nuclear attack being followed by a real launch in response).

For a list of some problems that occurred, see Appendix C at https://web.archive.org/web/20010412195518/http://www.iy2kcc.org:80/Appendices.htm (the International Y2K Cooperation Center glitch list). You'll see that most of these are quite minor. In many cases, the impact was greatly reduced because the problem was identified as a Y2K problem, and the bank, insurer, etc. readily admits to a mistake. Some of the glitches include failure of devices (like your watch), such as the breathalysers used by the Hong Kong police to test drivers for alcohol.

15 nuclear power plants had issues, all minor (7 in the USA, 2 or 3 in Japan, 2 in Spain, at least 1 in Russia). Since plants were being monitored for problems, the problems could be fixed, or the affected system shut down and the back-up system used instead, or the plant shut down. Pre-2000 testing at one power plant (Peach Bottom, Pa.) led to more serious difficulties, as the electronic sensor system crashed. Workers used the old-fashioned gauges (retained as a back-up system for safety), so no major risk, but if something like that happened unexpectedly in a nuclear power plant with sloppy procedures, it could have been a big problem. That the problems were quite minor is testament to the thoroughness of Y2K checking and fixing in nuclear power plants, and the nuclear industry's generally vigilant attitude to computer systems (the US nuclear industry wrote the book on validation and verification of software).

Other safety-critical systems (e.g., air traffic control, electrical power grids) were also checked thoroughly and no major problems occurred (but still some minor issues).

One that shouldn't have happened was the British NHS sending incorrect Down's syndrome test results to 154 pregnant women, with 2 terminations resulting (and 4 babies with Down syndrome being born to women who had been sent incorrect negative test results). It shouldn't have happened because unusual test results is one of the things that should have been watched for. For a newspaper story on this: https://www.theguardian.com/uk/2001/sep/14/martinwainwright

While possible issues in banking, finance, police, and various other computer systems were well-known, a less-talked-about problem was data in general. Where different components of a complex system send data to each other, that data is often time-stamped. Data time-stamped with dates 100 years out can cause problems, especially if the receiver is careful and checks the time-stamp (and potentially refuses to use the data, and waits forever for the "correct" data). This is the root of (most of) the problems that occurred with the nuclear power plants, failures of medical devices, and more. Where that's in a safety system, the safety system can fail. A nightmare scenario was a major air traffic control system crashing due to such problem, leading to further crashing (of aircraft).

So, in summary, many things broke. The things that might have broken dangerously or expensively were typically checked thoroughly, so most of the breaking that happened was minor. Where things did break, the impact was usually greatly reduced due to awareness of the problem.

Not something I've watched/listened to, but I see a potentially interesting recording of a lecture on the topic: https://www.gresham.ac.uk/lectures-and-events/what-really-happened-in-y2k