Then at least in that sequence you’re into unused join nonces, though that doesn’t mean you necessarily are at other points in other trials.
Most likely though that moves the prime suspicion to receive issues. Is the code up to date? Are the DIO’s correctly connected? Something you can do is get a cheap USB logic analyzer and use it to watch both the SPI bus and the DIO’s - you want to see that measured from the DIO transition marking the end of the uplink transmission, SPI operations then setup a receive window beginning just before each of the 4 and 5 second marks, and that the receive timeout DIO doesn’t fire until a bit after that expected time.
If you have physical access to the gateway, you may be able to get its transmit LED on the logic analyzer record, too - but you can generally assume the gateway’s timing is right if it transmits at all - if Internet or server latency doesn’t get the response back in time, the gateway won’t transmit at all (IIRC there’s a checkbox in gateway registration to indicate that the gateway can accept packets as soon as they’re calculated, vs the old situation without a queue where packets had to be held on the server until just before transmit time, meaning that even with a 4 second delay only a few hundred milliseconds were available for Internet delays)