Live data from Hacker News

Post-mortem for last week's incident at Kagi

status.kagi.com

101–110 of 186 posts

Re: Post-mortem for last week's incident at Kagi

#101

Earlier quoted context omitted.

Yes, exactly. Or 5 cents for the first 100 searches, 2 cents after, something like that.

They do have the FastGPT api which is approx 1.5cents per api call

So raise this to 5c for first 100 and 2c thereafter and we have a happy customer?

Re: Post-mortem for last week's incident at Kagi

#103

> While we do offer unlimited searches to our users, such volume was a clear abuse of our platform, against our terms of use. As such, we removed searching capability from the offending accounts. Don't advertise something as unlimited if it's not actually unlimited.

Unlimited searches as a real user is not the same thing as running a bot against the service.

Real users can also run a bot for their real use cases, the correct way out is not to mislead

Re: Post-mortem for last week's incident at Kagi

#104

> While we do offer unlimited searches to our users, such volume was a clear abuse of our platform, against our terms of use. As such, we removed searching capability from the offending accounts. Don't advertise something as unlimited if it's not actually unlimited.

Unlimited searches as a real user is not the same thing as running a bot against the service.

Just advertise it as 10,000 per day if that’s what it actually is. Any sane user will see a number like that and know they don’t have to worry about the limit.

Re: Post-mortem for last week's incident at Kagi

#105
post #36
post #9

Earlier quoted context omitted.

Hi there, I'm Zac, Kagi's tech lead / author of the post-mortem etc. This has 100% been a learning experience for us, but I can provide some finer context re: observability. Kagi is a small team. The number of staff we have capable of responding to an event like this is essentially 3 people, seated across 3 timezones. For myself and my right-hand dev, this is actually our very first step in our web careers - this is…

Mh, I work quite a bit in the OPs-side and monitoring and observability are part of my job, for a bit of time now too. I'll say: Effective observability, monitoring and alerting of complex systems is a really hard problem. Like, you look at a graph of a metric, and there are spikes. But... are the spikes even abnormal? Are the spikes caused by the layer below, because our storage array is failing? Are the spikes caus…

Running voodoo analysis on graph spikes is indeed a fool’s errand. What you really need is load testing on every component of your system, and alerts for when you approach known, tested limits. Of course this is easier said than done and things will still be missed, but I’ve done both approaches and only one of them had pagers needlessly waking me in the middle of the night enough to go on sleepless swearing rants to coworkers.

Re: Post-mortem for last week's incident at Kagi

#106

Aaaahhh, it's crazy how much this incident resonates with me! I've personally handled this exact same kind of outage more times than I'd care to admit. And just like the fine folks at Kagi, I've fallen into the same rabbit hole (database connection pool health) and tried all the same mitigations - futilely throwing new instances at the problem, the belief that if I could just "reset" traffic it'd all be fixed, etc...…

I was wondering the same thing. They would have some writes indirectly due to searches, say if someone chooses to block a search result. They’re also going to have some history and analytics surely. But yeah it’s not obvious what should cause per search write lock contention…

You know, in retrospect, I think Kagi expects O(thousands) searches per month per user, so doing per-user usage accounting in the DB is fine -- thanks to row-level locking.

Well, at least until you get a user who does 60k "in a short time period"... :-)

Re: Post-mortem for last week's incident at Kagi

#107
post #84

I was one of the users that went and reported this issue on Discord. I love Kagi but I was a bit disappointed to see that their status page showed everything was up and running. I think that made me a bit uneasy and it shows their status pages are not given priority during incidents that are affecting real users. I hope in the future the status page is accurately updated. In the past, services I heavily rely on (e.g.…

As an engineer on call, I have been in this conversation so many times: "Hey, should we go red?" "I don't know, are we sure it's an outage, or just a metrics issue?" "How many users are affected again?" "I can check, but I'm trying to read stack traces right now." "Look, can we just report the issue?" "Not sure which services to list in the outage" ...and so on. Basically, putting anything up on the status page is a…

IMHO, any significant growth in 500s (that's what I was getting during the outage) warrants mention on status page. I've seen a lot of stuff, so if I see an acknowledged outage, I'll just wait for people to do their jobs. Stuff happens. If I see unacknowledged one, I get worried that people who need to know don't and that undermines my confidence in the whole setup. I'd never complain if status page says maybe there's a problem but I don't see one. I will complain in the opposite case.

Re: Post-mortem for last week's incident at Kagi

#108

Earlier quoted context omitted.

nah, unless you were the intern, you should be safe it's like Star Trek where you're fine unless you're the one wearing the red shirt

If I ever run a company, all the interns will get red shirts

The contractor badges at google were red until at least 2015. And as it was explained to me, it was not a coincidence.

Re: Post-mortem for last week's incident at Kagi

#109

> While we do offer unlimited searches to our users, such volume was a clear abuse of our platform, against our terms of use. As such, we removed searching capability from the offending accounts. Don't advertise something as unlimited if it's not actually unlimited.

Don’t abuse the system.

Re: Post-mortem for last week's incident at Kagi

#110
post #84

I was one of the users that went and reported this issue on Discord. I love Kagi but I was a bit disappointed to see that their status page showed everything was up and running. I think that made me a bit uneasy and it shows their status pages are not given priority during incidents that are affecting real users. I hope in the future the status page is accurately updated. In the past, services I heavily rely on (e.g.…

As an engineer on call, I have been in this conversation so many times: "Hey, should we go red?" "I don't know, are we sure it's an outage, or just a metrics issue?" "How many users are affected again?" "I can check, but I'm trying to read stack traces right now." "Look, can we just report the issue?" "Not sure which services to list in the outage" ...and so on. Basically, putting anything up on the status page is a…

Connect your status page to actual metrics and decide a treshold for downtime. Boom you’re done.
Post reply on HN