Not sure how, but cabal update seems to work fine despite of this. At least the couple of tests I did. Maybe is a http vs https? I am not sure how cabal downloads the index.
Is there a general status page or account one can look up to see the overall status of various services?
The hackage issue was unrelated – a disk space misconfiguration leading to slow performance as zfs struggled to keep up. It is now resolved.
Cabal update continued to work because cabal automatically will fall back on mirrors when hackage is nonresponsive – a very nice and slick bit of engineering.
I think stack update was working. I think the JSON errors that you saw are those reported by the hackage-security package as it works through its mirrors.
Stack relies on Pantry which relies on the hackage-security package. That package works through the mirrors in a local copy of the mirror cache provided (I think by the Hackage project) at https://hackage.haskell.org/mirrors.json when the main domain is down.
EDIT: What I am not sure about is whether the first mirror - http://hackage.fpcomplete.com - is still a service provided by FP Complete, or whether it was something that transferred to the Haskell Foundation when Stackage was transferred to the Foundation. If it is still with FP Complete: thank you FP Complete.
Oh, a distributed cache. Nice! The closest we have is users are able to run their own hackage instance and mirror – but that is heavyweight and not super-automated. We also have tools to create lightweight package-only mirrors. But nothing sort of in a caching-on-demand space.
Cabal does of course cache all packages its built – so there is a store for each individual user. But it would be very slick to have something sitting at a middle-layer between the two – and probably not a ton of work to build. Honestly – just a local varnish might be enough on its own!