Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upptime – GitHub-powered open-source uptime monitor and status page

upptime.js.org

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#71

Post by messutied »

superice wrote: post #70

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…

I think most monitoring services offer at most 1 HTTP request / minute checks, is there really need for lower intervals?

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#72

Post by lma21 »

messutied wrote: post #71
superice wrote: post #70

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…

I think most monitoring services offer at most 1 HTTP request / minute checks, is there really need for lower intervals?

Unless the alert is managed by a downstream automated system, I don't see the point of having an internal that is smaller than 1 minute -- 1 second or 1 minute won't differ much for a human interaction, right? Am I missing something?

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#73

Post by lma21 »

geerlingguy wrote: post #45
fahrradflucht wrote: post #5

Earlier quoted context omitted.

I'm pretty sure the reason for "the recent Travis thing" is called Idera, Inc.

Yeah but bleeding money due to abuse of a free service surely contributed to the decision to sell. 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.

Does 1/hour really count as /Continuous/ integration/delivery?

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.

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#74

Post by jotato »

superice wrote: post #70

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…

> 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

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?

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#75

Post by strogonoff »

anandchowdhary wrote: post #68
strogonoff wrote: post #66

Earlier quoted context omitted.

Interesting idea, and props for well-executed landing page at Koj! 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).

> Interesting idea, and props for well-executed landing page at Koj! 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 w…

Wondering, do you have a sort of vocabulary of all the emojis you use in commit messages, or it’s more inspiration-based?

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#76

Post by [deleted] »

c16a wrote: post #44
judge2020 wrote: post #42

Earlier quoted context omitted.

Well, outside of when GH goes down, managing this in the cloud allows you to make more stuff 'serverless' - you don't have to worry about hardware failure and the maintenance burden that comes with moving stuff [data, code, secrets, logical volumes, etc] to a new host when you need to decommission the existing hardware. As long as you commit to the repo manually every few months (GH will stop crons on repos that have…

The idea behind the "serverless" approach is a lightweight process which doesn't spend any measurable CPU / memory (at least for healthchecks). GitHub Actions is the opposite of that. After all, cloud is someone else's computer - in this case, several other projects can use this computer for something more important than health checks.

[deleted]

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#77

Post by superice »

jotato wrote: post #74
superice wrote: post #70

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…

> 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 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?

Internally it's about accuracy of reporting. If you do high uptimes (say >99.95%) rounding starts to matter.

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.

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#78

Post by superice »

lma21 wrote: post #72
messutied wrote: post #71

Earlier quoted context omitted.

I think most monitoring services offer at most 1 HTTP request / minute checks, is there really need for lower intervals?

Unless the alert is managed by a downstream automated system, I don't see the point of having an internal that is smaller than 1 minute -- 1 second or 1 minute won't differ much for a human interaction, right? Am I missing something?

Yes it does. It takes about 20 seconds to place a call. If a mission critical system goes down, customers will refresh a grand total of 3 times, then call. As I explained in the sibling comment, reporting downtime within a minute is the difference between 'what do you mean the system is down?' and 'yeah, we noticed and are working on it'.

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.

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#79

Post by jjeaff »

xahrepap wrote: post #13
jjeaff wrote: post #12

Earlier quoted context omitted.

You say "spin up" which in my mind implies a whole VM. I think surely actions are just run in sort of a container of some sort like a lambda. I would think it should be rather efficient to run a github action.

Yes and no. Depends on tenancy requirements. I know with docker and other common Linux container strategies you would want to keep each tenant on their own VM. A container isn’t safe enough. 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)

Ya, but I doubt that is the case with actions, because I don't think you really have full access to everything. You provide a yaml file and their software runs that yaml which could easily exclude any dangerous commands. 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.

Re: Upptime – GitHub-powered open-source uptime monitor and status page

#80

Post by jjeaff »

thayne wrote: post #29
jjeaff wrote: post #12

Earlier quoted context omitted.

You say "spin up" which in my mind implies a whole VM. I think surely actions are just run in sort of a container of some sort like a lambda. I would think it should be rather efficient to run a github action.

I'm pretty sure GitHub actions do use a whole (though probably lightweight) VM. And I think AWS lamdas do as well, or at least used to.

Well, if lambdas are using VMs and have sub-second launch times, I don't think using a lot of github actions would cause much overhead.
Post reply on HN