As someone who works on a SaaS project that has vastly different utilization by different customers, sometimes limits are more a way of ensuring that customers

As someone who works on a SaaS project that has vastly different utilization by different customers, sometimes limits are more a way of ensuring that customers understand the expected usage of a product and don't get you into the situation where a customer is adversely impacting all the other customers and has the attitude of "you said it was unlimited!" I've definitely seen postings here and elsewhere about CloudFlare having to deal with sites whose usage is so much that it impacts other customers. While it's in their ToS, it isn't stated as a limit and there's often a backlash. I'm guessing that the GitHub "limits" are likely soft. As long as the usage doesn't start adversely impacting their systems, they might not care. But there are certainly cases where an individual customer might do something that they would want the ability to shut down because it is getting to the point that it causes reliability or performance issues and these limits give them cover to do that. User expectations were set that this isn't an unlimited free-for-all. When you architect any system, you do so with certain usage patterns in mind. If you're running a SaSS project, customers might (quite innocently) not understand your intention for the service and use it in a different way that works for them, but puts your systems in pain and adversely impacts other customers. http://githubengineering.com/rearchitecting-github-pages/ http://githubengineering.com/rearchitecting-github-pages/ Based on that post, it seems that any individual file is located on one active fileserver and one standby fileserver. That means that if any one individual file becomes extremely popular, it has the potential of impacting other customers located on the same box. It seems reasonable that this architecture works well for the vast majority of GitHub Pages sites, but that it wouldn't work well for some users. Yes, there are ways of mitigating the problem. You could write a balancer that isolated high-volume customers. You could do a more complex replication scheme to more locations. But that's work not needed for the vast majority of users and their intention probably isn't to become a high-volume webhost. Similarly, one can imagine a customer with a multi-GB repository making automated changes every few seconds. It's a little hard to imagine, but in a long tail of SaaS customers, people do all sorts of weird things. Now they're potentially having more data to be copied faster than they can actually copy (a spinning disk won't write multiple GB in under a few seconds). Or maybe they have a certain number of "copy workers" and they don't want loads of large jobs from one customer backing up the queue. We've definitely had customers ask our support about usage that's 1.5x some of our "limits" and honestly we probably wouldn't have even noticed. The limits are there for us to set expectations that resources cost money and we've architected our systems in certain ways that we expect certain types of usage. But in a SaaS world, someone has always (usually innocently) found something they think is a perfect fit for what they want when it really isn't made for that.