Upptime – GitHub-powered open-source uptime monitor and status page
upptime.js.org
upptime.js.org
It’s truly been one of my worst experiences with any CI.
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!
Can you point out the code responsible for executing the http connection? If it at all modularized, I'd like to plugin code for a different kind of check.
(Are you thinking of supporting customized checks through plugins?)
It is utilized by this function here: https://github.com/upptime/uptime-monitor/blob/master/src/up...
If you're thinking about different checks, perhaps you can explore this too? I have no idea where to start... https://github.com/upptime/upptime/discussions/73
You can run a self-hosted GitHub or GitLab Runner with your own resources: https://docs.github.com/en/free-pro-team@latest/actions/host...
GitLab [Runner] also runs tasks on cron schedules.
The process invocation overhead for CI is greater than for a typical metrics collection process like a nagios check or a memory-resident daemon like collectd with the curl plugin and the "Write HTTP" plugin (if you're not into using a space and time efficient timeseries database for metrics storage)
An open source project with a $5/mo VPS could run collectd in a container with a config file far far more energy efficiently than this approach.
Collectd curl statistics: https://collectd.org/documentation/manpages/collectd.conf.5....
Collect list of plugins: https://collectd.org/wiki/index.php/Table_of_Plugins
Is there a good way to do {DNS, curl HTTP, curl JSON} stats with Prometheus (instead of e.g. collectd as a minimal approach)?
Personally I’m way of relying on GHA too much (I have a suspicion they might start introducing restrictions), but if it works it works.
I see you’re also using TypeScript, so I’m definitely taking a long look at your github-actions-starter (thanks for sharing).
Thanks so much! This isn't Koj's "Show HN" (expect that soon!), but we're doing some interesting stuff, both tech- and "home and living"-wise. Happy to hear any additional feedback for koj.co as well!
> I have a suspicion they might start introducing restrictions
I definitely think so, unlimited minutes for all public repos can only be sustainable with many many paid orgs buying expensive minutes. If restrictions kick in, I think I'll keep the "GitHub issues to status page" part of Upptime and have some integrations with self-hosted monitors or third-party services that then open those GitHub issues automatically.
> I see you’re also using TypeScript, so I’m definitely taking a long look at your github-actions-starter (thanks for sharing).
Enjoy! We're using Svelte and TypeScript everywhere at Koj, we also have some other starters here if you're interested: https://github.com/koj-co.
Microsoft had much deeper pockets, but if people start using GH Actions as free Lambda, basically... the gravy train can't go on forever.
I figure it would be a better medium for GH to throttle CI workflows to something more reasonable, like 1/hour at minimum.
They made 2000 action-minutes-per-month for free for a specific reason. I think they can bare the cost and the potential 'abuse' inhibited by free orgs.
Why not just use a dedicated uptime service with a free tier? I've been using UptimeRobot [1] in the past - they give you 50 free checks at the same refresh rate of 5 minutes.
I would think it should be rather efficient to run a github action.
So if this is your org’s only action. Then you’re probably spinning up a VM. If you have other options. You’re probably not adding any overhead.
(Edit: grammar)
> I don't think you really have full access to everything
You do.
> their software runs that yaml which could easily exclude any dangerous commands
Categorizing dangerous commands is impossible to do accurately by just looking at a yaml file.
> Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.
I'm not sure what this means. The paid hosted runners are not any different from the free hosted runners, but free runners can only be used on public repos.
Edit: from https://docs.github.com/en/free-pro-team@latest/actions/crea... "Actions can run directly on a machine or in a Docker container".
https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
https://docs.microsoft.com/en-us/azure/azure-functions/funct...
A small price to pay, it seems, to lock more people into GitHub/GitHub Actions. We're talking pennies, here.
They probably don't care about one person doing this, but if tens of thousands of repositories start doing this it becomes a problem.
> They run all of Azure, after all.
They get paid for that.
I suspect Microsoft is less interested in making a profit on every single part of the github ecosystem, and less likely to change the pricing/limits for actions. But of course only time will tell.
They drop me a good amount of credit to get my account running while I wait to upgrade.
And that doesn’t include the synthetic monitoring part.
That said, we use site 24x7 at work and it works well enough.
“ (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...
I'm glad! I've been using GitHub Actions for many interesting things apart from building Upptime, like:
- COVID-19 nonprofit work: https://github.blog/2020-08-13-github-actions-karuna/
- Open-sourcing all my life data: https://github.com/AnandChowdhary/life
- Open-sourcing my GitHub notifications: https://github.com/AnandChowdhary/backlog
- Converting all Twitter "following" to lists: https://github.com/AnandChowdhary/twitter-list-sync
- Writing notes and generating a summary: https://github.com/AnandChowdhary/notescurl 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.
The idea that polling should be done every minute or so is madness. Here are a few thoughts:
- If your app is meaningfully impacted by even 1 requests-per-second extra you have more serious problems to fix.
- Rounding matters if you do high uptime. If 4 minutes downtime per month is high (e.g. ~99.99% uptime), rounding to the nearest minute could make a 50% difference in your downtime reported.
- You can speed up your resolving of any downtime by a almost a minute without any extra effort in terms of teaching people or having better processes in place. Even if the gains are small, this is the logical place to spend a tiny bit more to gain a minute on every downtime.
- For most things, standards don't need to be that high. But it doesn't hurt to have quicker feedback, and the cost is neglegible.
- Some systems are quick enough in recovery that you don't notice the downtime, like when switching over to a hot replica. Your customers will notice any short downtime that occurs. Why? Scale. Your polling client is only one, but you might have thousands or millions of customers. Chances are at least one of them notices a hiccup. You should view it as your responsibility to ALSO be aware of this, even if you choose not to actively improve on this.
- To phrase it bluntly: standards are too damn low in DevOps.
This is 100% the driving force behind pricing at my saas (lean20.com). Requests are cheap, but from our analysis people want 1/min intervals. What is your use-case of it needing to be more than that?
If you want the less bureaucratic version: downtime for mission critical apps means customers call. Immediately. If your SaaS to manage a container terminal is down, that means the container terminal is down. That turns very expensive very fast. Knowing the system is down before you receive the first call is vital. Monitoring once a minute and taking 2 failing calls before reporting means you have a 2 minute delay. That is the difference between telling the customer 'yes, we've noticed and we're working on it' versus 'what downtime?' on the phone
EDIT: I looked into your startup, and definitely love that pricing model. That seems like the right stategy, and beats other monitoring solutions easily at scale (>10 hosts seems to be the cross-over point roughly). If you can report downtime within say 20s of it actually occurring via a webhook or Slack integration or so, I'd love to have an invite. E-mail is in my profile.
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.
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.
For anyone interested, you can generate custom variations of them here and see more from work from the original artists:
I did a quick calculation and got to ~3000 minutes per month: https://twitter.com/AnandChowdhary/status/132966786702177075....
> 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
Absolutely agreed, but it makes the site so much cuter! I just made a Docusaurus template and used it for a bunch of my open-source landing pages, like https://upptime.js.org and https://stethoscope.js.org, but yes, it needs updating!
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).