Preface

When using Uptime-Kuma, I encountered a very frustrating problem: how can I most effectively receive real-time notifications when the health status of my site changes? Uptime-Kuma supports many notification methods, but the ones usable for normal people are just these few:
SMTP
This works, but it requires setting up instant notifications on the corresponding email client. However, I generally don't like to check emails as soon as they arrive, so email notifications can serve as archives but are not suitable for instant notifications. Speaking of which, 139 Mail does support SMS notifications, but the format of the SMS notifications is not very easy to modify.
webhook
This also works, but it's best if you have an existing webhook receiver. If you have to build it completely from scratch, it is not recommended.
Telegram
This actually works too, but it is not suitable for use in China. Friends who have their own methods can set it up themselves, which is also quite simple.
AliyunSMS
This was originally feasible, and I even spent 30 RMB to buy a package. In the end, I found out that the SMS template must contain the following 4 variables:{name}{time} {status}{msg}, but the SMS template containing these 4 variables could not pass the review. The customer service adamantly refused to approve 4 variables, suggesting that 3 were enough. Maybe they were afraid I would do something bad?

So the 30 RMB went down the drain...

In addition, there are DingTalk, Lark, WeChat Work bots, etc., but none of these are suitable for me (those who already use them can use them), as I don't use them in the first place...

It seemed like a dead end at this point, but then I discovered Bark.

Deploy bark-server

First, use Docker to install a Bark server. It is recommended to install it on home broadband with a public IP address, or on a cloud server. The installation command is as follows:

docker run --name bark-server -dt  --restart=always  -p 8080:8080 -v /docker/bark-server/data:/data finab/bark-server

Parameter explanation:
-p 8080:8080
Specifies the mapped port of the container. You can modify 8080 according to your actual environment requirements.
-v /docker/bark-server/data:/data finab/bark-server
/docker/bark-server/data is the mount directory on my host machine. Change it according to your actual environment.

After running, access it directly using a browserhttp://你的公网ip:8080/ping, if you get the following response:

iOS terminal settings

Then download the Bark app from the App Store. After opening it, the following interface will be displayed:

By the way, Bark provides a usable message server by default, which is the api.day.app mentioned above. Frankly, it can be used directly, but it is public, and others can see the messages you push. So for security, we ultimately still need to use a self-hosted server.

Click the "+" sign in the upper right corner:

In the server address field, enterhttp://你的公网ip:8080, and then click Done in the bottom right corner, as shown below:

Then go back to Uptime-Kuma and select Bark in the notifications:

Note that the Bark endpoint address in this red box is the address in the red box on the interface we just successfully registered above, as shown below:

Here, we just need to click the copy button above to directly copy this address, and then paste it into the Bark endpoint in the Uptime-Kuma notification. The following ”change this to your own push content“ can be modified according to your own needs. This is the content of the notification received by the app when there is a problem with the monitored site.

At this point, the Bark notification setup for Uptime-Kuma is complete. I set up several Bark notifications at the same time, corresponding to iPhone, iPad, MacBook, and Mac mini. Once a problem occurs, all devices receive notifications in real time. It is very practical, and I no longer have to worry about SMS.

Configure public network access

If you want to publish to the public network, you need to choose the most suitable publishing method based on your actual environment and the reverse proxy you use. You can refer to several of my previous articles:
1、Docker Series: Building Your Own Reverse Proxy Based on NPM Using Docker
2、Linux Panel Series: Configuring Reverse Proxy and Publishing Using Non-443 Ports
3、Home Data Center Series: Getting Cloudflare for Free via Domestic ICP-Filed Cloud Hosts to Achieve Fast Access to Domestic Sites from Abroad
4、Home Data Center Series: Getting Cloudflare for Free via Home Broadband Without Public IP to Achieve Fast Website Building (Universal)

Among them, the 1st and 2nd methods are suitable for environments with a public IP but without a legal 443 port (home broadband, non-filed cloud hosts), where non-standard ports need to be added after the URL (if using Cloudflare to build a website, no port needs to be added, but you need to customize the origin server port, which you can refer to:Home Data Center Series: Solving the Problem of Having a Public IP but No Legal 80 or 443 Ports for Website Building via Cloudflare's Origin Rules). The 3rd method is suitable for cloud hosts with ICP filing, and the 4th method is suitable for all environments (including environments without a public IP), which is also my recommended method (regardless of whether your environment has a public IP, because this method does not require running HTTPS traffic directly on the public network).

4 Summary

Bark is a simple Webhook receiving API

The Bark server is essentially a lightweight, HTTP-based API receiving service. It is not responsible for user authentication and does not persist data; it only does one thing: receives HTTP requests with a specific path structure and forwards the content as push notifications.

Client registration to obtain a unique identifier (token)

Each Bark client (such as a certain iPhone) needs to first establish a registration connection with the Bark server. After registration is complete, it will obtain a unique token.
This token is the identifier of this client, equivalent to its ”address”.

How Webhook Platforms Call Bark

Any platform that supports webhook notifications only needs to send a request in the following format to the Bark server:

https://your-bark-server.com/token/推送内容

As long as the request format meets Bark's convention, the Bark server will identify the target device and forward the message content.

Workflow of the Server

1. The Bark server receives the client request (i.e., the webhook request)
2. Parses the token in the URI to find the currently registered and active client device
3. Extracts the notification content from the path and parameters
4. Constructs and sends push notifications to the client (e.g., via Apple Push Notification Service)

Why Bark is Considered a Simple Webhook Implementation

• Clear request structure, no authentication process required

• Uses paths to distinguish target clients, avoiding complex data interactions

• The client maintains an active connection, making pushes almost instantaneous

• Essentially a transit service based on “URI matching + parameter content extraction + push”

Note: The summary content in this last section was added later and might seem a bit abrupt alongside the overall content, but it doesn't matter, I think it's better to include this section.