Drobo 8D resets regularly

I’m really disappointed in my Drobo 8D. It resets itself every few days. Support indicates that my brand new disk drives are taking longer than expected to respond, thus some write queue backs up, and the result is the Drobo eventually crashing. It doesn’t say the drive is bad, nor take it out of service. It just crashes. Then Mac OS reports the disks weren’t ejected properly. There is no way for me as the end-user to see any indication of a failing drive. The information is hidden away in an encrypted section of the “Get Diagnostics” output. I just get system resets until eventually one day a drive light turns red. Now I can take that drive out of the Drobo, stick it into another device, and do read/writes to every sector successfully. Perhaps there are bad sectors on the disk, and when they are remapped by the disk controller, the original write request takes longer to complete. The Drobo software should be able to handle that, and not reset itself. What is the point of having such a RAID system if it resets itself? It seems that this Drobo 8D will eventually just become a door stop, and the drives will be moved into another RAID enclosure from a different vendor. I can only hope it does a better job than this Drobo 8D.

Debugging errors of this requires careful thought.
Some basic issues may be the HDD. Are they SMR or CMR or certified for NAS use? WD has had an ugly phase of non compliant disks, and Drobo is pretty finicky about which it can accept. After all, it is data integrity they are trying to protect. Better safe than sorry.
Other issues may be the OSX, it’s drivers, extensions, even hardware such as the T2 chips and it’s drivers. Things were definitely not ‘stable’ until 10.14.4 in my experience and several Apple Security Updates later too. (even these had issues where ‘downgrading’ updates led to more stability !!)
This is because putting the hardware on the machine does not equal full compatibility to something as new as a TB3 protocol; the hardware may have a bug which required a workaround in the driver, and or the driver was not stable.
Lastly, it may also be because of the cable. As simple as it may appear, TB2 and TB3 cables are pretty complex things, and they have IC chips inside them to control the traffic. These can run into trouble too.
Finally, it may be down to the Drobo unit itself.
I have not had the misfortune to meet such instances, and most issues were explainable or had maneuverable workarounds.
Hope the above is useful.