Yes and no, respectively.

A cgi-bin is as highly available as the web infrastructure hosting it, which as the cgi-bin author you don't need to know anything about.

A cgi-bin cannot "crash" because there is nothing long-running to crash. It is only run on demand.

I think it is easy to make the case that CGI was the proto-serverless api and that the serverless offerings we have today are an evolution of the CGI approach.

edit: typos

And cgi-bin was really just an evolution of inetd (or ucspi-tcp if you worshipped at the altar of djb). You didn't used to have to worry about binding to ports or long running processes. Something would just send you a message on stdin and you replied on stdout.

It can be, and not necessarily. `cgi-bin` can be as stateless as you want it to be. Just as stateless as lambdas, or other forms of "serverless" functions.

And thus, it can be distributed as well as any other stateless function.

I ran an e-mail service with 2m users. The web frontend was written in C++ (no, I don't want to go back, but we had a pretty nice custom framework) all served up as a CGI, behind a load balancer.

If our code crashed, the next request would just get served as normal. If Apache crashed or a frontend crashed, another one would just take its place. High availability cgi-bin is trivial.

sure, cgi-bin with a big load balancer

That depends on you and the SLAs you have in place with your cgi-bin provider.