The proper reaction is not just “fail the test” and be done (or pass it and be done).
If you cannot find the root cause and trigger it consistently, report it as an intermittent bug and let management to decide if it is so obscure and inconsequential that it does not have to be fixed, or if more resources should be spent digging up the root cause.
QA is not to assure quality but to assist the management with providing information about the status of the application to make informed decisions when allocating resources.
Logging a trivial bug (which will not be fixed) has no business value so it is just a waste of time: yours (as a tester), and people who will triage the bug and decide to ignore it. (I discuss examples of what I consider “trivial” later).
When in doubt, enter the bug into the tracker.
Talk to the product owner about whether the bug is trivial (and should be ignored) or whether should be reported and fixed. Communication (in person) is cheap; don’t communicate via the bug tracker.
In our company we have “product owners” – a person responsible for making decisions about their respective areas, and they are part of the triage team. So this is to give them a heads up, to avoid entering into the bug tracker something which they will reject during bug triage anyway, to avoid a waste of time.
It might make sense to track even bugs which should be ignored – so the decision to ignore them is recorded, and no more attempts to enter them are made. But your bug tracking system might not be the right place to enter them (might have too much overhead) – maybe some lighter resource, like a wiki page of known glitches (so other testers may learn what is a glitch and what is an honest bug needing to be reported). But for most situations, such a formal list of known glitches would be also too heavy-handed – it can be learned by communicating with other more senior testers.
Process is no replacement for communication.
A trivial bug is something really trivial: say, sometimes the page is not correctly redrawn when the window size changes, in a browser used by only a small proportion of your users, and can be solved with a page refresh, and has no consequences, and you cannot force it to happen consistently.
Another example of a trivial intermittent bug would be a traceback which occurred only once or very few times, where say some object was not properly instantiated, occurring at a time when there was some other outage/service disruption with a data provider, in code which had not changed for many weeks. Can you prove it is related to the disruption? Unlikely. Is it a good time investment to track down the root cause? Unlikely. So you don’t enter it to bug tracker.
On some days we have several such tracebacks, and entering them into the bug tracker would make no business sense. The situation is different if they are numerous, and consistently appearing – those are well worth tracking and fixing.
Few commentators insist that every bug is worth reporting. Let me disagree. maybe we disagree what is a bug.
I am working in QA for few years, and found quite a few issues where we decided NOT to enter it to the bug tracker and NOT waste time investigating it, because we had bigger fish to fry. I am jealous if you have the time and resource to dive into each rabbit hole you find, but we don’t.
Certainly we do have bugs entered years ago and still not resolved. Some are closed after few years, because parts of the system changed a lot since reporting, and we do not noticed it since.
But also certainly we do not enter every single one wayward traceback found in logs into bug tracker and spend hours investigating it.