PingMe: one command for alerts across every messaging platform

The problem it was built to solve

The origin story in the readme is unusually direct and it explains the design better than a feature list would. PingMe is a personal project to satisfy a need for alerts, and the observation is that most major platforms have integration to send alerts but it is not always useful, either because you are stuck with one particular platform or because you have to do a lot of integrations. The need was for a small utility that can be called from backup scripts, cron jobs, CI/CD pipelines or from anywhere to send a message with particular information, and that can be shipped everywhere with ease. Everything is configurable via environment variables, and you can export the logs or messages to a variable which is sent as the message, and the project describes itself as a swiss army knife sort of tool supporting multiple platforms. The consequence for a user is that switching the destination platform is a change to an environment variable rather than to code, which is exactly what a cron job needs.

Fifteen services, and they are not interchangeable

The supported list is long and it is worth reading as a list rather than as a count. Discord, Email, Gotify, Line, Mastodon, Mattermost, Microsoft Teams, Pushbullet, Pushover, RocketChat, Slack, Telegram, Twilio, Zulip and Wechat. The repository topics list the same set with the addition of alert, cli and webhook among the general terms, and the go.mod confirms which are implemented as separate client libraries rather than by hand-rolled HTTP. There is a Gotify API client, a Pushover library, the Go matrix client, a general notify library that covers several of the simpler push services, a Twilio client and a Wechat client, with the Discord, RocketChat and Teams SDKs appearing as indirect dependencies pulled in through the notify library. That tells you something real about the implementation, which is that a substantial part of the platform coverage is delegated rather than written from scratch. For a user, the practical consequence is that the per-platform fidelity varies, because a service reached through a general library gets less attention than one with a dedicated client.

Installing it, five different ways

The installation routes cover every platform a user might be on. On Mac and Linux with Homebrew it is a single tap command:

brew install kha7iq/tap/pingme

There is also a shell script, which by default installs to the system binary directory and therefore needs administrator rights, and which can take a custom path as an argument so it installs somewhere inside your home directory instead. The script is fetched over curl and piped to a shell, in two forms, one pointing at the raw file in the repository and one at a shortened link. On Linux there is the Arch User Repository with two packages, one that builds from source and one that ships a prebuilt binary. The manual route sets a version, an architecture and an operating system as environment variables and then downloads the release tarball, unpacks it, marks the binary executable and moves it into place. On Windows the tool is available through a scoop bucket that you add and then install from. And there is a Docker image on both Docker Hub and the GitHub container registry, with a latest tag that always tracks the newest release.

The webhook server turns it into a service

The newer capability is the one that changes what the tool is for. PingMe can run as a standalone webhook server to receive and dispatch notifications via HTTP POST requests, and the readme frames it as suited to monitoring tools, CI/CD pipelines and custom applications. The quick start exports the credentials for the services you want and then starts the server, which listens on all interfaces and port 8080 by default, with flags to change the host and the port. The request body is a small JSON object naming the service, the message and an optional title:

curl -X POST http://localhost:8080/webhook \
  -H "Content-Type: application/json" \
  -d '{
    "service": "telegram",
    "message": "Hello from webhook!",
    "title": "Test Alert"
  }'

The endpoints are three, a POST for the webhook itself, a GET health check and a GET for server information. The authentication is optional and has three modes, an API key list, an HMAC secret and basic credentials, all selected with an environment variable naming the method, and the Docker Compose example shows the same variables passed into the container so the two deployment styles configure identically.

Securing the webhook, and the container defaults

The authentication section is the part to read if you expose the server, because the default is no authentication at all. Three methods are documented. The API key mode sets a method variable and a comma-separated list of keys, the HMAC mode sets a method and a secret, and the basic mode sets a method with a user and a password. Any of them is selected by the same variable name, and the compose example shows the API key form in use with the port published and the credential variables alongside the service credentials. The Dockerfile is deliberately minimal, built on Alpine, copying the binary for the target platform into the system binary directory, exposing the default webhook port and setting the default command to start the server. The target platform is a build argument, which is what makes the same image work across architectures, and the image is built from the release binary rather than from source, so the container is a packaging exercise rather than a build exercise.

The GitHub Action, the CLI surface and the build setup

For CI there is a first class action, available on the marketplace and in its own repository, and the usage in a workflow is a step with the action pinned to a version. The CLI itself is built with the urfave cli library, which gives the standard help output showing the command name, the usage line and a description, and the description in the readme notes that the tool provides the ability to send messages or alerts to multiple messaging platforms and also email, with everything configurable through environment variables and command line switches. The go.mod requires a recent Go release and a small set of direct dependencies, with the platform clients as direct and the rest of the ecosystem pulled in transitively. The Makefile is short and conventional, with a setup target that downloads modules, runs code generation and tidies the module file, a test target that runs with the race detector and a five minute timeout, a format target using gofumports and a gci import ordering pass, a lint target running golangci-lint, and a combined target that runs the tests and the linter in sequence.

Editorial conclusion

PingMe is a good fit for someone with a backup script, a cron job or a CI pipeline that needs to raise an alert without caring which platform the recipient reads, because the same command works for all of them and the configuration is a set of environment variables rather than code. It is the wrong choice if you need delivery guarantees or retries, since the tool is a thin client over each platform's own API and the documentation makes no such claim. It is also the wrong choice if you need to send rich interactive messages, since the message body is a string and the content type per platform is whatever that platform accepts. It is the wrong choice if you will not keep API tokens in the environment, and that applies to the webhook mode too, where the same variables hold the credentials. Before adopting it, read the service list rather than the feature list, because the fifteen services differ in what they can render. The project is MIT licensed, the last push was on 2026-07-15, and the current release is v0.2.7 from 2025-11-20.

Frequently asked questions

Official sources

1. kha7iq/pingme on GitHub
2. License: MIT
3. Project website
4. README
5. Releases