by littlestymaar on 12/27/20, 7:50 PM
Given that in recent years Github had more downtime that your usual app, the github-powered part may be more of a liability than an asset ;).
by anandchowdhary on 12/28/20, 5:40 AM
Maker here, I made Upptime as a way to scratch my own itch... I wanted a nice status page for Koj (
https://status.koj.co) and was previously using Uptime Robot which didn't allow much customization to the website.
It started with the idea of using GitHub issues for incident reports and using the GitHub API to populate the status page. The obvious next step was opening the issues automatically, so the uptime monitor was born. I love using GitHub Actions in interesting ways (https://github.blog/2020-08-13-github-actions-karuna/) and have made it a large part of my toolkit!
by Karliss on 12/27/20, 8:25 PM
Abusing version control and CI service as database sounds like a way for ruining it for open source projects that actually need it. The recent Travis thing didn't happen without reason.
by simon1573 on 12/27/20, 8:48 PM
I've been using updown.io for my side-projects the last 18 months and I'm very happy with the service. One comment pointed out that status monitoring is expensive - I think I've payed a grand total of $5 for these 18 months, so I don't agree at all.
by ec109685 on 12/27/20, 8:29 PM
Neat. A lot of the status page solutions are very expensive. Up to 1500 a month:
https://www.atlassian.com/software/statuspageAnd that doesn’t include the synthetic monitoring part.
That said, we use site 24x7 at work and it works well enough.
by maxandersen on 12/27/20, 9:29 PM
From GitHub usage policy:
“ (for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden); or”
I think this would qualify as serverless application...
by andrew_ on 12/28/20, 12:49 AM
As a proof of concept this is fascinating, and I'm thankful the author chose to share it. It's got me thinking of how I might otherwise leverage Github Actions in unconventional ways. Acknowledging the potential abuse implications that others have mentioned in the comments, it's still a mind-expanding PoC that's going to make me think about things a little different in the future.
by npmaile on 12/27/20, 11:38 PM
Why are there so many things these days about using some super complex cloud solution hack for something that can fundamentally be done easier and more efficiently from a cron job on a raspi zero on a home network.
curl yoursite.tld | some_script_that_parses_the_result and generates an uptime page > githubpagescontent.md; git commit -m $(get_the_current_time.sh); git push origin master
for $20, you can get the same thing with waaaay less stuff going on behind the scenes and without taking advantage of the ci resource for something it wasn't fundamentally meant for.
by superice on 12/28/20, 11:28 AM
Might be a little off-topic, but I don't understand why monitoring solutions are both so expensive and simultaneously tend to offer such a low resolution. HTTPS-calls aren't particularly computationally expensive, why does 10s or lower poll intervals not exist for cheap? I expect that for most of these monitoring services, redundancy and fixed development costs are much more expensive than the actual underlying infra, so the marginal cost of extra HTTP calls is probably low. Why not offer high resolution as an offering to set you apart from the competition?
by victorhooi on 12/27/20, 9:31 PM
One limitation of their approach seems to be that it must be published in a public Github repo - it can't be a private repo.
This means it might not be so suitable for internal, or local apps - only public facing websites.
I wonder how difficult it'd be to make a mode for Upptime, that used say, local agents, and posted the results to a local webserver, rather than to public Github Pages.
by dinkleberg on 12/27/20, 9:35 PM
I like using GitHub Actions for small automation tasks like this as well, but I'm curious what the execution time is for each of these runs. GH Actions has been reliable for me, but it tends to be rather slow due to the architecture. Also I feel like this would chew up all my build mins pretty quick (this is 8000+ runs/month).
Side note, I find it hilarious how many sites use those generic "modern" illustrations which have absolutely nothing to do with the service or page context. I know it's tempting to keep up with the modern design trends, but picking from one of those illustration packs almost always leads to questionable choices.
by stefanha on 12/30/20, 9:55 AM
@anandchowdhary Can you explain the security implications of using Upptime?
Does it need a token to access all of the user's GitHub repos?
That's a little worrying because the code does not reside in the git repo it's fetched from third-party repos by the GitHub Action. Does this mean the user has no way of auditing and locking down the code to prevent future compromises to third-party repos?
If yes, then an attacker that compromises Upptime or one of the third-party GitHub Actions could hijack all of the users repos (including non-Upptime repos owned by the users).
by interactivecode on 12/27/20, 8:52 PM
This is great! Sure even github might have downtime. But keeping track of the status for small side projects this is perfect
by imdsm on 12/27/20, 11:58 PM
I understand how people are saying "why not just do X?" but let's all try to keep in mind that this thinking goes against our ethos of invention and reinvention. As the adage goes, "if you have to ask why, you wouldn't understand".
by sepbot on 12/27/20, 10:07 PM
by djabatt on 12/27/20, 11:23 PM
I get the negative comments sentiment, but the idea is clever.
by dstroot on 12/27/20, 8:23 PM
In the not too distant past GitHub was hit by some massive DDOS attacks themselves.
by superkuh on 12/27/20, 11:41 PM
Anything that is "GitHub-powered" as a requirement is not open-source.
by freebuju on 12/27/20, 9:20 PM
Love the name. Simple and original :)