I've used it and am happy with it. It's reasonably reliable, but has more downtime than the big providers. I wouldn't run mission-critical software that needs 5 9's uptime on it, but for anything else it's fine, certainly for personal projects. They're transparent with any outages, so you can check up on the outage history on their blog: https://prgmr.com/blog/
It's a small business run by a few people (though it's been around for 10 years, so a pretty stable one), which has the pros and cons that go along with that. The tech staff is good, techies who know what they're doing and generally assume that you do also. So if you send a request or problem report, you aren't going to get a form reply that asks if you tried turning it off and back on again. But it's just a handful of people, so if there's a major issue, fixing things is pretty manual and slower than at places that have armies of 24/7 devops staff.
One specific thing I really like about it: it gives you SSH access to a proper text console, in case you want to install a custom OS, recover a broken install, etc. Most VPS providers give you console access, but most do it via VNC in the browser, which is not my favorite way to do sysadmin work.
Yeah, you have a choice of using their prebuilt disk images, running one of the officially supported OS installers from the console menu, or downloading your own installer. The list of prebuilt images and supported installers is here: http://wiki.prgmr.com/mediawiki/index.php/Distributions
You can install a custom OS. But it can be difficult to use an installer we don't provide right now because we only allow serial console access, not VNC. This means most installers won't work out of the box. Worst case you can dd an image to the disk using ssh from the rescue image.
FYI we don't do overage charges right now. For network, if we can't throttle your traffic down then we will shut your service off.
Our blog is a little misleading these days in that for downtime for individual servers, we started emailing customers directly rather than posting to the blog. This is because we want to make sure customers see the downtime notice. We also got confused responses sometimes to the blog wondering whether a given service was affected or not and if we email directly there is no such confusion.
I think our worst case downtime barring about 5 services this year has been the following:
* 2.04 hours downtime from start of maintenance window, planned due to security upgrade - 2016-11-18 (gave proportional credit)
This is a total of up to 12.69 hours downtime over the year so far, assuming downtime started at the beginning of maintenance windows (it usually started after.) Of that 6.05 hours, or less than half, was unplanned.
So far this year there's been about 336 days or 8064 hours. 12.69/8064 is 99.84% uptime overall, which is significantly lower than we would like. For some servers the uptime has so far been significantly better in that there were no hardware failures, one of the security upgrades was unnecessary, and the turnaround time for the remainder of the security upgrades was much faster than for this particular server.
For this particular server, the largest downtime contributors were security upgrades and network outages in that order. For network downtime, we got around to setting up our second upstream but there's a number of single points of failure we should take care of in 2017. There is also some additional scripting we should probably do that would cut down on the network downtime a lot, such as automatically taking down BGP if connectivity beyond the first hop is lost.
For the security update downtime, I think our most realistic bet right now is to get ourselves on the latest version of Xen once it comes out. That will hopefully have a stable implementation (not a technology preview) for live patching.
