SantiagoVargas

Hahahaha. Goal isn't to read them from the map, just extract the info. But yes, without the chat/other workflows I would concur

Imported all of the available research on AI, ML, and NLP for the past 10 years. The map is massive but it is still queryable. Posted it on reddit as an AMA, feel free to drop any questions related to those topics and I'll send back the answers with the citations. Happy to answer some questions about the tech behind it on here as well.

Posted this on reddit as an AMA and thought I'd share on here. The map has around 100k papers and all of them are grouped semantically (clustered by the ideas discussed in the papers). The purpose of the map is for a literature review, found it interesting to explore the field this way.

Completely agree - was surprised myself with the response we've received. Saturated market but the 10x cheaper/easier to set up seems to be resonating with other 1-3 person teams. Don't plan on bringing it to the enterprise-level though.

I've heard a lot of good things - seems like the standard for those that don't mind self hosting and managing the alerts. Our goal with this product is to make sms monitoring easily accessible and hands-free (especially for teams/devs that want to focus on the product/marketing and move quickly). Thanks for sharing these resources.

Very true - our goal is to help companies keep their customers amazed. Especially when starting out with early adopters. Though perhaps not something that can scale as easily.

From a technical standpoint? Or how it works as a user?

Hi - just sent you an email!

Thanks. It's simple but seems to be a common need. One of those tools many companies end up having to build but keep internal.

Just looked into Rootly - looks great. This was an mvp launch to test the concept but I'll see about building the multi-cloud setup. Nice to see another Western alum here.

Haha not quite! We host our main startup (Website + app) on AWS and have been using it for around 7 months internally, it's worked great for us so far.

But if something crazy like the 2023 outage happens again then you're absolutely right. Though you'd likely get a news alert for it - our fallback :)

If we get enough traction we'll look into a multi-cloud setup to mitigate that risk. For now our goal is to help with notifying you when your server goes down due to more common reasons.

Not quite - just thought of what I would actually pay for it. Looked at others and saw most done for you solutions were monthly subscriptions ~$9. Couldn't see myself being excited by that pricing model + another dashboard to manage, so I made it $5 for the year and built the most simple solution that's easy to set up and reliable (while not losing money).

Almost all monitoring services I found target enterprise, and the ones that don't are self-hosted. This solution is for the small teams/indie devs that just need to know when their servers down. Might raise the price though, thinking the low price might work against me for quality perception. What do you think?

Sounds good - I appreciate the feedback, will let you know when it's up later today.

Different use cases, ours is for people who prefer simplicity and just want a text to know if their server goes down. We charge $5 for the year, this service charges $108 (But is aimed at larger enterprises and provides more analytics like monitoring logs/custom status pages). I'm sure their service is great for their enterprise customers, but for smaller teams I feel a text when your server goes down solves the key pain point.

Thank you for your comment! Wow - That sounds like a very important use case. Please feel free to reach out to me if you encounter anything while getting set up [email protected]; I'll double check once you sign up that everything is configured correctly (any unauthenticated endpoint that retuns a 200 response will work, best is /health).

Hi there thanks for purchasing! Currently we have it set to just one endpoint per account (MVP Launch) but let me add support for more today. How many endpoints are you looking to monitor?

If a tree falls in the forest and no one is around to hear it, does it make a sound?

You bring up a good point. I think it to be less of a problem for more established companies that don't face unexpected outages too often. When we were starting out with our mobile app however this wasn't the case, and each outage meant downloads lost which were critical for getting early feedback. I see it as a bigger pain point for early founders/small teams whose server could see a lot of volatility.

So far we haven't encountered any false positives (been using it for around 6 months) but perhaps with the wrong endpoint that could be a problem. I'll keep an eye out for that.

I appreciate the feedback! Just implemented this, hadn't thought of that. Cheers.

I suppose you're right, unless your server goes down more than 50 times. I saw it as credits that expire in a year, would be a bit scary to offer monitoring in perpetuity for $5 if they didn't expire.

Right, we ping the servers every minute. Since we charge a one-time fee the credits expire after a year, but the service is scaleable. To answer your question I'll give you some more context:

The architecture uses scalable AWS serverless components (Lambda, SQS, DynamoDB) and is well-suited to handle a large increase in monitored endpoints. The primary scaling mechanism is the automatic concurrency scaling of the Lambda functions processing messages from SQS queues. Should we scale to 10,000 endpoints we do expect some bottlenecks that would require optimizing i.e. increasing lambda timeouts/memory etc. but we'll cross that bridge when we get to it.

For the actual sms sending our numbers can send up to 100 sms texts/second.

Correct. It requires an unauthenticated endpoint that retuns a 200 response. So usually this is the /health endpoint, but as long as we can send a ping it works.

It's a one-time 4.99 fee (covers a year of monitoring or 50 downtime events).

It's aimed at indie devs/startups shipping ideas quick. Built it for ourselves while we were starting an app under the aws free tier which occasionally went down when usage spiked. Notified us to fix it quickly before losing users that could download the app but not create an account. It can be set up in 30 seconds without needing to code anything, so mainly for coders that want a quick and easy solution.

So not aiming for enterprise on this one, made the pricing quite accessible and with minimal features.

For the health endpoint as long as it only returns a 200 status code (without disclosing info like tokens or resource info/server configurations) then the risk is very minimal.

Built YourServerIsDown.com as a side project that we needed for our startup... anyone else have the issue of not finding out quickly enough if your server went down?

For our app it's super important as if our server goes down, users can download the app but get stuck at the sign in flow. There's subscription services out there that do more in-depth monitoring but this is all we needed.

I listed an alternative solution below for those wanting to build or customize their own solution, ours just gets the job done, is quick to set up, and you can avoid the monthly twilio/sms fees.

Other alternative we received as feedback for those interested: "If any one wants an AWS Native way and assuming it has ALB you can target elb metric 503 via Cloudwatch Alarm and create an output to an SNS topic that goes to Slack, or use AWS chatbot/q, or set number as destination for sms via sns"