A failed battery on a nicer RAID controller will usually cause its overall performance to drop quite a bit.

When a program writes bytes to the file system, those bytes aren't guaranteed to arrive on the underlying, permanent storage. They're cached for some variable amount of time in the memory of the host operating system.

In UNIX, calling fsync will force the OS to flush any outstanding writes to the underlying storage, which should mean they're safe. So far so good.

Nicer RAID controllers have a lot of high speed memory memory, and they are basically their own operating system. When they receive a write from the host OS, and their battery is good, they lie to the host OS and say that the write went through all the way to disk/SSD, even though it probably didn't. This has the effect of making the fsync call return a lot more quickly.

The bytes are still safe in this case because if there's a power loss of the whole server, there's enough battery power left to allow the controller to write through any data it lied about writing.

When the battery goes bad, by default the RAID controller will cease its lying about when the bytes it receives are written all the way through, which has the effect of slowing things down.

I can't say how lower IO performance caused the https problem in question without more details, but there are a lot of possible correlations.

NB: For brevity, I simplified a lot of how this stuff works, so some of what I said above isn't 100% accurate as stated.

Not the OP, but a guess: A lot of RAID cards will switch from writeback mode to writethrough when the battery is low, because they can't guarantee that the (battery-backed) cache will persist across a power failure. Writethrough mode makes writes significantly slower, which could cause problems higher up the stack.

Guessing the battery died and the clock reset throwing off a https parameter. Happens to my daughter's tablet when she forgets to charge it and then she can't connect to https sites without resetting the clock.