The only thing coming to mind right now is possible issues with the json or the content length header. If the length of the json doesn’t match up with the actual size of the json, the send would probably be rejected. (You’d get a 5xx I think.) Unfortunately the only way you’d see that 5xx or details on why the send failed would be to turn on the modem’s “deep” debugging, log the full output to a text file, and then scroll through the thousands and thousands of lines of output looking for a time when a send failed to see what the response was. Or you could get *really* lucky and catch it in the act. I’ve been trying to catch the LTE XBee3’s in bypass mode in the act of crashing to see if I can figure out why it sometimes locks up but I haven’t managed.
You could also download the csv from MonitorMW and go line-by-line against a logger csv until you find a gap. See if the data in the gap is in any way different from the surrounding lines. Does one of the values have more or fewer digits when there is a gap? (As in, something like 4.65, 4.66, 4.62, *4.6*, 4.61 where the 4.6 is suddenly “shorter” because of the missing trailing 0.) I’m kind-of grasping at straws though.