talonx

AI slop-code has exacerbated the problem and GitHub is not able to keep up. If you look at the last 12 month's outage reports from GitHub's own status page, many of them mention capacity issues as an underlying cause.

They don't have straightforward status pages or APIs to detect outages - I think that's the reason they are not listed.

Services like Cloudflare and Twilio have so many POPs globally that one or more always have an outage going on. Then there's the question of whether it's a major outage or a minor outage. Even though major status page providers like Atlassian and Incident.io have public status APIs (Cloudflare uses Atlassian), it takes more than just parsing them to determine what is "down" and at what granularity.

I run an outage detection service - and some of these issues, like parsing hundreds of - sometimes undocumented - status APIs, make for an interesting engineering problem.

Oh thank you! I sorely miss the original HS website.

And worse - when I open Google News all the news under Technology is about the latest mobile phones and "gadgets".

I remember Firefox used to have this cool feature where you could detect any RSS feeds on the page you have open.

Now if I don't see it on a page I check the page source - some blogs don't advertise the feed but it's there.

BetterStack did report issues with some of their services, but they were not very informative.

- What I'm working on right now - https://incidenthub.cloud - It monitors cloud/SaaS status pages. I'm working on some white-labeling features.

- New ideas - Easier way for new users to try out the product. It's currently a few steps, but I want to optimize it for specific user personas.

You're welcome.

Ah, to be honest I did not look at the tour.

Thanks for explaining #2 - but the text "Auto" might be a bit non-intuitive for a user.

Congrats on launching this.

I understand this is an initial launch, so not trying to nitpick, but these are what felt like would add immediate value:

- Adding a social login like Google would allow faster signups.

- Maybe I missed it - but I could not find any options for automatic monitoring which would update the status page. There are manual options for adding an incident.

- Post-signup, it takes me to a login page. Why ask to enter the company name instead of user/pass directly?

- If I could click on "Components" on my dashboard (/admin) and go directly to the Components page, that would be nice.

I like it that you took the time to write a privacy policy that is both readable and precise, especially as to the list of third-party services.

Working on my SaaS that monitors third-party status pages - https://incidenthub.cloud/ It's a one-person project I started last year.

My biggest technical challenge remains dealing with the immense number of different APIs (and not-APIs) in the different status pages out there. Marketing remains my biggest overall challenge as my background is engineering, but I've learnt quite a bit since I launched this.

They published a detailed incident report - https://webflow.com/blog/july-28-webflow-incident-report

What I find disturbing here is the number of people who are supporting him saying that he is a victim of the system.

Irrespective of his skills or how broken the system is, dishonesty can never be condoned.

I'm building Incidenthub.cloud - a B2B SaaS that monitors public status pages of third-party dependencies.

It was born out of a personal need in past roles and teams. I launched it last year.

This HN thread is pertinent here - https://news.ycombinator.com/item?id=33368104

I'm building Incidenthub.cloud - a B2B SaaS that monitors public status pages of third-party dependencies.

It was born out of a personal need in past roles and teams. I launched it last year.

I see what you are describing. The pre-production/staging setup may not bring out cost increases caused by application changes, and by the time it is running in production for a while it has already caused a cost explosion.

We did face similar situations - but we fixed them after the cost went up on prod. I guess this has more to do with how much and how fast an "undetected" cost in pre-prod can explode in production. We used to keep an eye on the prod cost numbers after a deployment, and then tackle each one, because the increase was not that quick.

I'm not sure either about a "standard" way, so I'm just thinking aloud here, and I've not tried this myself:

For application changes, measure the difference in cost in pre-prod, in terms of percentage increase, between the previous deployment and the current one, and use that to estimate the possible prod increase. I suspect this will become messy very fast as the other factors to include would be num requests, CPU/memory usage, and so on.

Rather than focusing on accountability as the starting point, I would suggest building tooling and visibility so that cloud costs are visible across all layers including application and infra. Once you have this, accountability becomes easier.

Each application team should be able to view the total cost of running their service - and thus be held accountable to reduce costs when necessary.

Without data you are running blind. Cost optimization cannot be solved by a standalone team - it has to be owned by everyone.

Source: Personal experience reducing cloud costs in a slightly smaller team.

I suggest you ask in a more local community like the Remote Indian Slack channel. All the best.

I came here to comment about the same thing.

Non-paywall link https://12ft.io/proxy?q=https%3A%2F%2Fwww.theatlantic.com%2F...

Valid point about support but if you enforce it everyone will have to use it unconditionally.

Not having MFA opens it up to potential data breaches causing havoc.

No MFA?

These sweeping conclusions are extreme. As a regular listener (and occasional, amateur, performer) of classical music, I find it dismissive and ignorant that the author chooses to paint so many talented musicians with the same brush.

I built this tool to monitor third-party cloud and SaaS services and send notifications, primarily meant for techops/SRE folks. I built this based on my past work experience where I felt a need for such a tool and had to be satisfied with patched together scripts.

E.g. Getting alerted when my public cloud has incidents, my monitoring SaaS is unable to send alerts, GitHub has intermittent issues, Slack has trouble delivering messages, Stripe has payment failures for an edge case, and so on.

It was important to catch these issues before they impacted my apps. For paging services, I wanted to avoid potential disasters because my on-call teams were not receiving alerts (true story - AWS had an outage and PagerDuty was not sending alerts). For non-infra services like Slack, I wanted to know if there were message drops or delays.

There are RSS feeds for these services but I wanted a single place to monitor the ones I am using and be notified, rather than manually check 10-15 or more RSS feeds.

It's primarily meant for teams that want a simple way to setup such alerts.

I'm the solo dev on this project. I've been in backend development/ops most of my career, so my frontend skills are not great yet, which is evident in the UI :)

Would love to hear feedback.

Yes, but there is a report of him being around around 2022 also - https://web.archive.org/web/20220128114020/https://whyy.org/...

It's a pity that not more published research is available on this.

Very interesting. The author of the paper is around, at least according to the internet, at 90+ years of age and still practising physiotherapy.

I used to play classical guitar - not anymore. I fondly remember the Sor studies.