The client can say it doesn’t work, the user can say it doesn’t work. You can’t.
It is your job to discover the source of the problem and fix it if possible or explain why the system works this way. You’re paid for it and you have a whole arsenal of tools and techniques to detect the problem.
IDE with debugger, logs, monitoring tools, documentation.
Other programmers in your company. Developers who you keep in touch with.
Developers on discussion boards, stackoverflow, various discords and slacks, Facebook groups.
You can try “5 why’s” strategy (or any number of whys that is necessary).
Go with narrowing the problems down. Eliminate what is not necessary or what seem like it doesn’t. Execute step by step, function by function.
Verify the environment the bug appeared on and check it’s similarity to environments you debug on. Keep “a copy” of the production environment as similar as it is possible and try to reproduce the problem there.
Log output values, values in the functions and errors. Add logs to function just to see which path of execution happened. Search errors on the internet. Draw and debug code branches if you find it helpful.
Write automated tests with data that will reproduce the bug. This way you can quickly and stably repeat and verify your attempts to fix the bug.
Read the docs. Check that the language, library, or any other external system, works the way you think it does.
Verify if there is some bug reported in the library’s/system tickets or issues tracking system. Check if the recently updated library had breaking changes or change in behavior…
…or take a break, go eat lunch, drink the coffee, play ping-pong or play-station, go for a walk – just leave the problem for a couple of minutes, hours or till the next day and have a fresh look then. You may have concentrated your attention in the wrong place, ignored some symptoms and clues. Give your head some rest – it will reward you with clearer thinking, so you can spot the problem and fix it with ease later.