That said, the risky thing about this in particular is infrastructure products like StatusPage and PagerDuty and Runscope have to work all the time, every time.
If your site is down and PagerDuty doesn't alert you - you're an ex customer. If Runscope gets bogged down and you miss out on metrics for 10-20 minutes, and your clients start leaving - you're an ex customer. If StatusPage goes down in the middle of your outage, you're an ex customer.
And in all those situations, you're going to make noise on your way out (twitter, medium, whatever).
This is incredibly difficult for a solo, bootstrapped operation to achieve. It costs real money and takes real expertise to get that level of performance and availability out of your infrastructure (not to mention what you need to do in the application). This stuff is completely orthogonal to, say, writing the app itself. You can be an amazing Rails/Django/whatever developer and totally mess up your infrastructure - it's super easy to do so.
On the other hand, being a generic SaaS operation charging reasonable fees - no one has expectations of 100% availability, and if people can't access your invoicing app or recruiting backend or whatever for 20-30 minutes in the middle of the night - no one is going to complain.
What are your goals? To build some income? To learn AWS, PHP, etc? It sounds like you've got a couple of different goals here.
I suppose there's a lot more than a software problem behind SP.io, the 24/7 availability infrastructure etc. I'm not tied to that idea at all, it was just one of a few things I use in my day job that I thought I cold re-create with some improvements to areas I find annoying/lacking.