Operations | Monitoring | ITSM | DevOps | Cloud

Long time no post! Here are some updates of what’s been going on.

Healthchecks.io ping endpoints accept HTTP HEAD, GET, and POST request methods. When using HTTP POST, clients can include an arbitrary payload in the request body. Healthchecks.io stores the first 100kB of the request body. If the request body is tiny, Healthchecks.io stores it in the PostgreSQL database. Otherwise, it stores it in S3-compatible object storage. We recently migrated from a managed to a self-hosted object storage.

I semi-recently bought a used Roborock S5 Max robot vacuum, and installed Valetudo on it. The installation process involves rooting the robot, and gaining SSH access to it. Which got me thinking, could I get the robot to ping Healthchecks.io at regular intervals? When the robot runs into a problem (closes a door after itself, gets stuck, chokes on a loose wire) and cannot return to the base, it eventually shuts down.

Starting from today, Healthchecks.io users on all plans (Hobbyist, Supporter, Business, Business Plus) can invite an unlimited number of users into their projects. Previously, the limits were: 3 team members for Hobbyist and Supporter, 10 team members for Business, and unlimited team members for Business Plus. From now on, it is unlimited for all.

Over the last few weeks, I indulged myself in doing a few “nice to have” website optimizations. They were.

Healthchecks.io can now classify HTTP pings from clients as start, success, or failure signals not only by URL suffixes (no suffix, /start, /fail, /{exit-status}) but also by looking for specific keywords or phrases in the HTTP request body. The content filtering feature was already available for email pings, and now it has been extended to HTTP pings as well.

URLs) receive spiky traffic:. The Healthchecks open-source project includes a fully functional, tested and type-annotated ping handler written in Python. On self-hosted Healthchecks instances, when you send an HTTP request to a ping URL, a Django view collects and validates information from the request, then uses Django ORM to update a Check object in the database and insert a Ping object in the database. This approach is good for tens to low hundreds of requests per second, depending on hardware.

But I am also happy to incorporate features that enable or simplify self-hosting use cases. Examples include the first-party Docker image, the remote authentication support, the Apprise integration, the Shell commands integration. A more niche feature that has come up a few times is the ability to serve Healthchecks on a subpath. Typically Healthchecks would run on a root level of a domain:.

Healthchecks can now notify you about a failing check by opening a new issue in your chosen GitHub repository. Here is an example of how the GitHub issue might look: The technical side of creating a new issue is straightforward: GitHub has an API call for creating an issue. You make an HTTP POST request with an access token in a request header and the issue title, body, and labels in the request body. However, where do we get the access token from? The API call accepts three types of access tokens.

Webhooks are a powerful way to notify external systems about checks changing state in Healthchecks.io. Webhook notifications are available to all user accounts, paid and free. Webhooks were the second notification method supported by Healthchecks (the first one was email). The webhook delivery code started as a simple requests.get(user_supplied_url) and evolved. Today, the webhook integration in Healthchecks supports.