Yes, often. Intermittent bugs are the most annoying to deal with, especially when you don't even know what triggered the problem.
Unless the underlying code/infrastructure changes within the five days (and often, even if it does), there's no technical reason to assume that the underlying defect doesn't exist any more, even if you can't recreate it.
However, there is a cost/benefit judgement that has to be made. If it's an intermittent problem that doesn't happen very often, and/or the impact is small, closing the bug as "unable to reproduce" may be appropriate. Personally, I'd prefer to leave it open, so that if the problem is seen again, people are more likely to connect whatever they saw/found with an already open problem, but there's no reason to keep it open if, for some cultural reason, open defects are seen as a problem.
I would consider it a problem if you're being asked to close the bug as "fixed," or something similar, because you have no reason to believe the problem was fixed, and it's going to make understanding the actual quality of the code base much more difficult. There's a big difference between something that has 100 fixed bugs, and one that has 50 fixed bugs and 50 "unable to reproduce" bugs.
Now, one thing that these bugs probably indicate is a need for better logging and/or error toleration/recovery code, but, again, there's a cost/benefit judgement that needs to be made.
In terms of handling them, you have to look at the impact, the frequency, and the expected usage. I spent a few weeks tracking down a security problem, for example, because it could have exposed data that shouldn't have been exposed, and our customers really care about that. Similarly, if you have something that only happens 1 of every 100,000 times you run a testcase, it may or may not be a problem, depending on how often you expect that function to be invoked.
[Edited to add]
One way you could look at this, though you'd have to get buy-in, which might be difficult, is that if there's a problem, but whatever diagnostics you have don't give developers/whoever enough information to debug/fix the problem, that that is a problem in and of itself. We call it a First Failure Data Capture problem in my area, and it's at least sometimes treated as more of a problem than the problem that was unable to be debugged. Because a customer will be annoyed (or more), if there's a problem, but they tend to get really upset if there's a problem they have to keep recreating because you can't explain how it's happening. So if we open a defect, and it isn't able to be debugged, we'll open a second defect for the inability to debug the problem.