Ideally they stop doing this with immediate effect!
But overall, what you are trying to achieve is all baked in, it’s just the problem is:
There is nothing in the ISM radio band that can ensure transmissions are received - it’s shared, anything could happen including large vehicles blocking line of sight. The metric TTI recommend is that you are able to cope with 10% packet loss. In a “normal” radio environment, what ever that is, but mostly not in the middle of an urban area or industrial park, then 1-2% is typical.
Hammering the uplink through is very bad for many reasons. Asking for a return receipt is very bad for many reasons.
The best strategy is to include overlapping payloads - so that the one sent for the second hour has a copy of the first hour - which can be made smaller by using a delta - the difference. Or even a moving window of three - current and previous two.
Alternatively you can send a request for missing data - so if your application receives the data for hour 5 but hasn’t had hour 4, very easy for it to detect in advance, it can send a downlink to request a resend of hour 4.
Another alternative is to send the data more than once with an appropriate random gap between uplinks.
Ideally your application can profile the at risk devices and set settings accordingly - this way you can make best use of a single small payloads with replay for the majority and either slight longer payloads for those prone to drop-out.
And as well developed as LMIC is, it isn’t as feature complete as other stacks, none of which I would use the LinkCheck mechanism to ensure complete data - I’d roll my own. But I would use LinkCheck to ensure local connectivity, having super glued the person moving the devices to the floor and the devices to their location. And keep a rolling log of data so if the super glue fails or a friend moves the devices or turns off a gateway - after they have been fired from the company, you can ask the device to replay a range of data. I would NOT rely on any stack to do anything useful or sensible with LinkCheck, I’d issue it at an appropriate interval from my own code and then follow the well formed guidance of TR007 which would suggest increasing the SF by a couple of points, retrying and then after a couple more attempts, trying a rejoin.
All of this is at the paranoid end of LoRaWAN robustness. Mostly gateways & devices just get on with their tasks for years. There is a school of thought that says if you HAVE to have every hourly reading, then this is not the correct technology. I’d disagree, I’d have a replay system or overlapping data and remove the saboteurs from the organisation.
As with all these situations, knowing what you are measuring would help enormously so we can comment more specifically.