> how do you handle errors, specifically timeouts here? We don't. We are using stateless HTTP semantics throughout. There is no web socket or other streaming

> how do you handle errors, specifically timeouts here? We don't. We are using stateless HTTP semantics throughout. There is no web socket or other streaming abstraction. You can key in a form, come back tomorrow and submit it and the server won't care (assuming business logic checks out). If the system is down at submission time and someone wants to retry after it comes up? No problem. The browser will give you an opportunity to resubmit the form data since the prior POST timed out. This has been a thing since ~forever. The end user experience when the service is completely down is that the browser displays "connection to server timed out" with various initial troubleshooting steps that the vendor manages. Either the server is up and everything works, or it is down and nothing does. Whatever partially-available thing we might be going for doesn't make much sense in my head.