Why a service? Seems the images are static coded from 0 to 100 and could easily just be a CDN reference rather then burning a service on every hit? URL/progress/1.png .. 100.png done.. :)
I assume various options to the look and functionality could be added and having the request go to an application as opposed to a static file first allows that opportunity. In addition, there is nothing stopping them forwarding the request to a cached result on a CDN.
But the current version is just an imaged coded on the fly and compressed on the fly.. It's burning CPU for no real reason.
If you want flexibility for future you can use a CDN path that includes options you want and later could switch to code the makes the requested image and caches result, returning the cached result.
I imagine the concept is to code the service for fun but I have to wonder to myself when something like this is shared but no concept of scale is considered. I know premature optimization is the root of all evil but isn't building a service to serve a static image basically premature optimization that "maybe some day I'll add more dynamic features".. :-)
Future expansion what about passing a height/width and making a larger progress bar, or a hex code for the color of the bar, or even a gradient? Lots more options and you can always cache the url request for a sane amount of time so its not a full hit to the app.
The problem I have with all of these images, is that they never sit centered with the text in the generated HTML. I love the idea, and I even have some different badges in a few of my repos but man is it frustrating to see sometimes haha. I'm probably the only one with this gripe, but it does drive me nuts.