Show HN: Statusduck – Website monitoring tool where the data is public | Hacker News Reader

Show HN: Statusduck – Website monitoring tool where the data is public

statusduck.io

78 pointsduckyio43 comments

Hello HN! We're excited to share Statusduck, an uptime monitoring tool where the data is publicly viewable.

There are an uncountable amount of uptime tools but we thought we'd put a fun spin on the concept by making another one where people can immediately set up a monitor without signing up. Just type in a website and our service will start pinging it every minute!

Open articleView on HN

Nice service.

A small comment. Let the url input be case insensitive (the https + domain part of course). Using it from mobile often set first H in https as uppercase and this mails your site fail.

A potential alternative is to set the following HTML attributes on the <input> field:

    autocorrect="off"
    autocapitalize="off"

URL inputs are otherwise also supported via <input type="url">

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Kudos for sharing this! Maybe you already have this in mind, but please sure to build in controls...so that your cool service is not turned into a network "weapon" against monitoring subjects/websites. Again, congrats on your launch!

100% keeping this top of mind. Thanks for the feedback!

Yeah, def seeing https://website.com and website.com and www.website.com, etc, being treated as "different" urls which means its a nice way to add just a little bit more load to servers.

Great point! I was only thing nefarious sources, but you're totally right it could also be to think about bugs or other similarly unintended/innocent reasons.

Meta note: Thank you for providing email address for signing up for a user account! It's disheartening how many new services nowadays require signing in with a Google account or similar and don't even offer just signing up by email.

Is this project open source? Or are there plans to open source it? Particularly as you are showing it under what I presume is a busines name "Drop Tables" (great name btw), I think it would be very helpful to your (assumed) goal of increasing your reach if the code was open. I for one would be reviewing it to decide if I wanted to hire/engage you, and am far, far more likely to be interested if I can see some real-world non-trivial production code :-)

You're reading our mind. Will open source a tidy version of this service in the near future

I like the name of your company. Are you funded?

Nope!

Yea I chuckled at "Drop Tables software". Creative.

Plans to expose site uptime as an RSS feed?

Wasn't initially but it's on the radar now!

I don't know if you're new to the space or not, if you're not then please disregard.

I'm new-ish to the space and what I've learned from interacting with a lot of long-time "uptime monitoring" dogs, is that they heavily use RSS for that sort of thing. After adding RSS to my uptime monitor (feature request from customer), I've started using it too and it's really pretty damn great!

Neat idea. Since everything is public, the next step obviously is to add a wall of fame/shame, right?

Here's the first entry! https://statusduck.io/52d5ac38-c982-4827-b4d8-4803dfa94252

8,000 ms to return a "Hey, you aren't authenticated, go home" ?

I'll take "It's Caching On" for $200, Alex

Assuming you're using "hackney/1.20.1" is it possible to get you to stop accessing my server? I signed up (no subscription) about 5 minutes ago.

Not the OP, but when we built this functionality for Heii On-Call https://heiioncall.com/outbound_prober we made sure (1) the User-Agent string points you to this page, (2) the User-Agent contains a unique string which we can decode and track back to the unwanted HTTP probe configuration on our end, and (3) also obeys /robots.txt. Trying to be a friendly robot :)

This is very clever. We'll definitely add this for tracking and managing monitors.

Just curious how you are pinging? Like are you doing a tcp-ping, icmp-ping, or performing an HTTP(S) connection?

HTTP(S)

Interesting. Where are you pinging from? I'm seeing much less https ping:

https://cloudup.com/c47xyiOpV4g

for https://statusduck.io/76687749-5690-48d9-9bd6-2f258f615978

and see ~500ms when curling from various places outside the EU.

It's fairly simple right now as we're on fly.io with machines in SJC and BOS. Being able to configure regions and having more clarity over the metrics is on the list

If you aren't already, you might want to do a HEAD request to cut down down on bandwidth usage. It'd be kinda messed up, but someone could just send you a few dozen gb's worth of data.

You'd get quite a few false positives

HEAD requests are sometimes handled separately, why not just drop the connection after the header?

It depends on what you're measuring. If you just want the "ping", then send a SYN packet, wait for a SYN-ACK. You're done.

If you want to get HTTP status message, send a HEAD request. If a server handles it differently than a GET without a body, that's not your problem. As an application developer, you might do this on purpose as a health check.

Sure, but if you're testing uptime, only the GET request matters. HTTP statuses are just one mode of failure. Timeouts are a major issue HEAD requests might not trip, for instance.

I'm not saying my solution is without flaws, just saying actually detecting "status" automatically isn't trivial and HEAD requests only expose one facet if this.

I’m not sure what you are saying makes sense. A HEAD request is (according to the http spec) a GET without the body. It can timeout, send cookies, status, etc. If someone decides not to implement the http spec properly, how is that your problem?

I mean if you want to provide value it is your problem.

Regardless, just because HEAD requests CAN time out doesn't mean they WILL, even in good faith. GET requests will surface precisely the same behavior browsers do.

It probably depends on what it considers to be a "response" it's very unlikely your 15ms is the total response, but probably just the initial server reply. 1400ms is more likely the actual full response.

Yeah, a HEAD request would likely be better. This 15ms check is also checking the body for some magical text to make sure the appropriate content is on the page and not an error message of some kind.

> it's very unlikely your 15ms is the total response

I'm seeing 9ms for the entire HTML payload on the server itself, and 90ms from my house. It's just returning a pre-generated html file, so it shouldn't be slow at all, bandwidth/RTT withstanding.

Lmk when you’re ready to build the statuspage side of the product.

honeststatuspage.com is ready for appropriate content.

This is a great product! Simple and elegant. I really appreciate your effort to build and share this.

I think people often want to build something big and even complex, but such a simple tool is already very useful for a large audience.

Looking at a few websites, the graph seems to show 0ms response time when the site was not pinged at all. Which is an mixup of null and 0 values.

Yep! This is a bug and we just need to add better handling of those errors and filtering as well. Good call out though. It makes things a bit noisy and also pollutes the leader board.

Using a *.berlin URL causes an invalid URL error. Do you have a fixed list of top level domains?

There's a trick to it:

Subscription

Statusduck Pro - $50/month

Included

Get email or Slack notifications whenever an incident is created or updated

Are you implying that monetization is a trick?

We intend to actively build this out! In order to do that while we are bootstrapped and also gauge interest, we decided that charging early will allow us to see what people are willing to pay for.

No way to delete an account though.

Reply on news.ycombinator.com