The web service log is not 100% reliable and should not be relied on for daily reporting.   

In AllTalk server, there are complex issues relating to multi-threaded access to the single log file.  On rare occasions, a problem with a client thread can cause log events to be lost because the log file remains locked by the problem thread . This is much more difficult to resolve than it appears - at any one time you might have 15 or 20 client threads trying to access the Log file.  To overcome this problem, Windows has a system of Thread Blocking called "Critical Sections."   Critical Sections are blocks of code that can only be executed by a single thread at a time and requires the thead to acquire a lock to begin executing the code.  AllTalk uses this model for writing to the log file.  There is a proviso that should the thread be unable to obtain a lock within 15 seconds, it will dump the log entry and terminate.  If the log entry was not dumped, this would represent a serious memory leak in AllTalk which would very rapidly cause the computer to run out of resources as each client connection may spawn 4 or 5 log threads on each visit.   In my investigations, it appears that something causes a thread to be blocked which then fails to release the file level lock on the log file.  Each subsequent thread, being unable to obtain a Thread Lock, OR should the problem thread terminate and the thread lock becomes available, the Log file itself cant be opened. 

The problem is resolved if a) The AllTalk services are restarted, or b) the time ticks over past midnight (a new file is created).

So  always remember that the web interface  log  is a useful tool, but not definitive for delivery information. 

The ATTrack service is 100% reliable though, so you should  always use the reporting tools in ATTrack rather than relying on the web page log data.

Glen.