compumike

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 :)

Ah yeah, these are no ordinary phone notifications. :)

Heii On-Call will keep alerting you with these “Critical Alerts” until you’ve manually acknowledged. (Or until it escalates to a teammate and they acknowledge…)

And at least on my phone they sound nothing like normal phone notifications, which I personally always have on vibrate and/or DND anyway.

Give it a try and I think you’ll like it.

If we eliminated the accounting fiction called "depreciation", and instead simply had all expenses deductible in the year they were incurred or paid on a cash basis (with net losses carrying-over to future years), this wouldn't have happened.

Thanks for the feedback!

We use iOS “Critical Alerts” and similar on Android that breaks through any Do-Not-Disturb settings. https://heiioncall.com/blog/better-alerting-for-heii-on-call... Would you be willing to give that a shot? It wakes me every time :)

(It’s configurable too; we have vibrate-only or silenced modes. Think old-school beeper.)

In the rare case that it doesn’t wake you, we have configurable escalation strategies to alert someone else on your team after a configurable number of minutes.

Heii On-Call is $32 per month total for your team — not per user. https://heiioncall.com/ (Full disclosure: part of the team building it)

The stream-of-thought reminded me of this depiction of meditation: https://www.sippan.se/_images/meditation.jpg :)

At Heii On-Call, we use Crystal to power the API server https://api.heiioncall.com/ as well as other internal components.

We use Puma in production.

That’s exactly right. Our code_region_size levels off a bit under 8 MB, so we set the limit to 16. In practice we see code_gc_count stays at 0.

Also for a practical tip on YJIT memory usage, note that there is a "--yjit-exec-mem-size" option, see https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#co... for more details. (This command-line argument is mentioned in the paper https://dl.acm.org/doi/10.1145/3617651.3622982 but not in this blog post about the paper.)

At Heii On-Call https://heiioncall.com/ we use:

    ENV RUBY_YJIT_ENABLE=1                                                                                                             
    ENV RUBYOPT=--yjit-exec-mem-size=16                                                                                                

in our Dockerfile for our Rails processes.

https://www.eia.gov/electricity/monthly/epm_table_grapher.ph... “Average Price of Electricity to Ultimate Customers by End-Use Sector, by State, August 2023 and 2022 (Cents per Kilowatthour)” — according to this, both $0.42/kWh and $0.06/kWh would be outliers, relative to any state-wide residential averages.

Can you clarify what's the "tremendous value" you're getting out of the Django admin?

At Heii On-Call https://heiioncall.com/ we are using Active Admin https://activeadmin.info/ for Ruby on Rails, which seems quite similar to the Django admin. In my experience, it's mostly useful as a fairly basic read-only view of what's in the database. In Rails, it's so easy to whip together a custom view that we tend to do that, and the Active Admin is nice to have but I wouldn't say "tremendous value".

https://github.com/compumike/crystal-docker-quickstart has been updated to 1.10.0 if you want to try it without installing anything

Thank you!

Rob Burbea Metta Retreat: https://dharmaseed.org/retreats/1084/ audio recordings with instructions and guided meditations

Hmm, both are "possible but not implemented yet". The engineering approach that some of our users do is running their own custom monitoring script (checking TCP connections, checking against a dynamic list) on their own infrastructure, and then just use Heii On-Call to monitor (via Inbound Liveness heartbeats / checkins) and alert on (via Manual trigger type) that custom monitoring script. Feel free to email us at support-at-domain so we can try to understand the use case better.

My best guess is that someone migrated DNS providers (or some engineer playing with infrastructure as code…) and it’s just an unintentional missing DNS record, oops.

The Hacker News API is still up: https://github.com/HackerNews/API https://hacker-news.firebaseio.com/v0/topstories.json?print=...

To @dang or whoever is reading at Algolia: you can set up continuous monitoring for problems at the DNS/TCP/TLS/HTTP layers from just your URL at https://heiioncall.com/ and we’d definitely alert you if the DNS record disappears or it’s otherwise unreachable for more than X minutes. (Email me if you need help getting it set up.)

Quite similarly, I imagine that if there were a chart sort of like like Figure 1 with "mental health" on the y-axis but having "total work hours per week" on the x-axis, there'd be a peak somewhere above zero hours but far less than 40 hours. (Controlling for same type of work, sames ages, etc.) Anyone want to guess what the peak x-axis value would be?

If you're looking for UptimeRobot alternatives, would you be open to taking a look at what we've been building at Heii On-Call https://heiioncall.com/ ? Curious to hear if that covers what you need or if there are any critical features we're missing.

Do you mean something like this page: https://heiioncall.com/status ? We use all of these internally at Heii On-Call https://heiioncall.com/ , and get paged when any of these triggers are alerting.

Edit: the subtle difference from the article is that it sounds like you want historical data, rather than present-state data.

Ah, by “join syntax” do you mean like this answer: https://stackoverflow.com/a/70803859 ?

Batch update many many rows at once with entirely different values.

(Agree that the “WHEN NOT MATCHED DO NOTHING” is effectively the default behavior.)

Use case is the Outbound Prober processes for https://heiioncall.com/ which can do thousands of HTTP requests per second, then aggregate all those row updates into a single query (or single transaction, which in practice is a single query).

We can do these batched updates very, very fast using INSERT … ON CONFLICT. No need to re-parse a differently shaped query, only a single index rebuild. Smooth :)

Is anyone aware of performance benchmarks comparing Postgres's new MERGE to the old INSERT ... ON CONFLICT?

The "WHEN NOT MATCHED THEN DO NOTHING" is very appealing, and we currently implement this with a transaction and a DELETE after the upsert because we want to do updates only, not unintentionally insert new rows.

Happy Crystal user and code contributor here. (Also created https://github.com/compumike/crystal-docker-quickstart in case you want to try Crystal without installing anything.) In my opinion:

- Slow compile times are still a pain for iteration.

- The REPL / interpreter mode is still rough around the edges.

As far as companies using Crystal:

- We’re using it happily in production at Heii On-Call https://heiioncall.com/status

- Kagi is using it for their search engine backend https://news.ycombinator.com/item?id=32687071

- Other companies using it list: https://crystal-lang.org/used_in_prod/

So just like the software industry story https://news.ycombinator.com/item?id=35614313 from a few months ago, is this a case where the accounting illusion of amortization (preventing companies from deducting expenses as they occur, and instead spreading out already-incurred expenses into the future) is creating a short-term incentive to destroy real products and services?

How is this better than simply working on a cash basis, letting companies take the loss in year 1 when they build X, and then, for tax purposes, carry forward those net losses against the future revenues? Sure seems much simpler.

https://www.amerigas.com/about-propane/propane-tank-sizes I've most commonly seen the 120 gallon size at homes that use it for a water heater.

Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web?

The constant churn of protocol deprecations, certificate expirations, rotations, etc. is like planned obsolescence on steroids.

> On the other hand, the HTTP status code does matter (sometimes a lot) to programs that hit the URL, including status monitoring programs; these will probably consider their checks to fail if the web server returns a 404 and succeed if it returns a 200. If you're pointing status checking programs at the front page of your just set up web server to make sure it's up, probably you want a HTTP 200 code (although not if the real thing you're checking is whether or not the web server and the site have been fully set up).

This is a subtle but important distinction…

There are so many layers now between a user and the application code. What if due to some misconfiguration or new image push or ___ the web server or load balancer or PaaS router or CDN or Cloudflare or whatever starts serving some default placeholder, or error message, or its own content up on my URL?

That’s why I’d argue for a non-200 status code for the default “hello” page.

And in production monitoring I’d use something like https://heiioncall.com/blog/enhanced-api-monitoring-with-exp... to verify the presence of some special header set only by your application, so you know that your desired code is actually being called. (In addition to asserting the HTTP status code.)

Pretty interesting! It makes me wonder, would anyone want a hosted version that runs checks against your production API endpoints / websites periodically? We have these basic capabilities (for example, assert headers, status code) as part of Heii On-Call’s HTTP outbound probes [1] but a more powerful assertion syntax might be interesting for some use cases. (Or are the basics good enough for Continuous Monitoring? And the advanced assertions more interesting for CI?)

[1] https://heiioncall.com/blog/enhanced-api-monitoring-with-exp...

> I'm running more complicated stacks to capture massive amounts of data in order to use it less and less. > […] > My experience is companies do not anticipate that the cost of monitoring an application can easily exceed the cost of hosting the application even for simple applications.

These problems resonate with me for sure, and after tackling them at other companies, they were part of our team’s inspiration for building Heii On-Call [1] as a lightweight, minimal monitoring platform for apps / APIs / Cron Jobs / etc.

Instead of “ingest all the metrics/logs” we have guides showing, for example, how to set up the most minimal possible Prometheus / Alertmanager, with the smallest footprint of CPU/memory/disk requirements. [2]

And for many of our users they don’t even use any of our Prometheus or Datadog integrations, and just stick with our dead simple out-of-the-box HTTP monitoring. [3]

Note that these address the “now” problem of monitoring: is it working now, or not? While most of the article talks about the “past” problem of monitoring (long term storage of logs, metrics; pretty charts).

The “past” part is the part that the author is pointing to as being rarely useful and the source of the cost and complexity. I think there’s probably still value in dumping whatever logs and metrics you want into S3 just in case you need to go digging one day, but for the most part, this is pretty low value. The relatively higher value and lower implementation complexity is in the “now”.

[1] https://heiioncall.com/

[2] https://heiioncall.com/guides/minimalistic-monitoring-and-al...

[3] https://heiioncall.com/docs