The fax log said 'sent successfully.' The recipient said they never got it

After sending a document via network fax (LAN Fax) from a PC, the recipient reported never having received it at all. Checking the multifunction printer’s fax log turned up something contradictory: for the same file, one entry showed “no result,” and a few minutes later another entry appeared showing “OK” - but sent to a number that didn’t quite match the intended recipient. Looking at the log alone, it would be easy to conclude “the file sent successfully” - but the recipient genuinely received nothing.

The log itself was already unreliable

This fax log raised at least two red flags:

1. The same file ID had two inconsistent status entries - “no result” first, then “OK” a few minutes later, sent to a number that didn’t look quite the same as the intended one;
2. The actual large, multi-page fax job had no corresponding “success” entry anywhere in the log at all - a job of that size should have left behind some final status entry, but none could be found.

When the log contradicts itself, it stops being the starting point of an investigation and becomes the subject of one

Switching to a completely independent send path to verify

Rather than continuing to untangle a log that already looked inconsistent, the more direct move was verifying with a completely independent send path: taking the same multi-page document and sending it by pressing buttons directly on the multifunction printer’s physical panel, instead of going through the PC’s network fax driver. The result: sending directly from the machine succeeded cleanly on the first try, with the log showing an unambiguous OK.

This comparison points fairly clearly in one direction: the problem sat in the network fax (LAN Fax) send path itself, particularly for larger jobs, not in the fax function or phone line generally - the machine sending successfully by itself confirms the hardware and phone line were both fine.

The response

For fax jobs with many pages, or for any important fax the recipient explicitly says they never received, default to sending via the multifunction printer’s physical buttons rather than relying on the network fax driver - especially once that driver’s own logs have already shown self-contradictory entries. Sending directly from the machine provides a verification path completely independent of that driver. In parallel, report the behavior to the device vendor or reseller to confirm whether the network fax driver has a known limitation or defect with multi-page jobs.

Lessons

1. A status log can itself be something that needs verifying, rather than an inherently trustworthy source of truth. Taking “the log says OK” at face value here would have wrongly concluded the issue was resolved, while the recipient’s actual situation kept going unaddressed;
2. Re-running the same operation through a completely independent path is an effective way to break out of a self-vouching log. A log written by the software/driver itself can’t prove that same software/driver is trustworthy - only stepping outside that chain and repeating the action through an independent method can actually verify the result;
3. For any physical action carried out through a driver or software intermediary (sending a fax, printing, relaying a message through a gateway), when the result is in doubt, just performing the action directly on the physical device once is often the cheapest, most direct way to get a clear answer - no need to first untangle the software layer’s log logic to get a definitive comparison.