Preface

When I was using Uptime-Kuma, I encountered a very tangled problem: that is, when monitoring the health changes of my site, how can I most effectively provide real-time notifications? Uptime-Kuma supports many notification methods, but normal people can only use these few:
1. SMTP
This is possible, but you need to set up instant notifications for the corresponding email client. I don't like to read emails as soon as they arrive, so email notifications can be viewed as archives, but not as instant notifications. By the way, 139 mailboxes support SMS notifications, but the format of SMS notifications is not easy to change.
2. Webhook
This works, but it is best if you have an existing webhook receiver. It is not recommended if you want to build it completely yourself.
3. Telegram
This actually works, but it is not suitable for domestic use. Friends who have their own methods can set it up by themselves, which is also relatively simple.
4. AliyunSMS
This was feasible, and I even spent 30 yuan to buy a package, but I found out at the end that the SMS template must contain the following 4 variables:{name}{time} {status}{msg}, but the SMS template containing these 4 variables cannot pass the review. The customer service will never agree to 4 variables and suggest that 3 are enough. Maybe they are afraid that I will do something bad?

So the 30 yuan was wasted.

There are also DingTalk, Feishu, WeChat for Business robots, etc., but these are not suitable for me (brothers who are already using them can use them), and I don’t use them.

It seemed like I was stuck in a dead end, but then I discovered bark.

Bark is a message push server that supports self-built services (actually it is also a webhook), and on Apple products (iPhone, iPad, Mac), you can directly install the client in the app store to receive notifications, which is exactly what I need.

Deploy bark-server

First, use Docker to install a bark server. It is recommended to install it on a home broadband or cloud server with a public network address. 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
Specify the mapping 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 the operation is completed, directly use the browser to accesshttp://your public network ip:8080/ping, if you get the following response:

That is success.

iOS terminal settings

Then download the bark app in appstroe, open it, and the following interface will be displayed:

By the way, bark provides a message server by default, which is the api.day.app above. It is reasonable to use it directly, but it is public, and the messages you push can be seen by others. So for safety reasons, we still have to use our own server in the end.

Click the + sign in the upper right corner:

In the Server Address field, enterhttp://your public network ip:8080, and then click Done in the lower right corner, as shown below:

After adding successfully, it will return to the initial interface:

Then click Register Device:
At this time, you will receive a notification asking you to allow notifications from the bark app. Click Allow here:

Then return to this page, which means the device has been successfully registered:

Then go back to Uptime-Kump and select bark in the notification:

Note the bark access point address in the red box, which is the red box address in the interface after we successfully registered above, as shown below:

Here we just need to click the copy button above to copy this address directly, and then paste it into the bark access point in the Uptime-Kuma notification. The following "Change to your own push content here" 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 monitoring site.

From now on, the bark notification setting of Uptime-Kuma is completed. I have set up several bark notifications at the same time, corresponding to iPhone, iPad, MacBook, and Mac-mini. Once a problem occurs, all devices will receive notifications in real time. It is very practical and I don’t have to worry about text messages anymore.

Configuring public network access

If you want to publish to the public Internet, you need to choose the most suitable publishing method according to the actual environment and the reverse proxy you use. You can refer to my previous articles:
1,Docker series uses Docker to build its own reverse proxy based on NPM
2,Linux panel series configure reverse proxy and use non-443 port for publishing
3.Home data center series uses domestic cloud hosting to get free cloudflare to achieve fast access to domestic sites from abroad
4.Home Data Center Series: Use cloudflare to build a website quickly with no public IP in your home broadband (general purpose)

The first and second methods are suitable for environments with public IP but no legal 443 port (home broadband, unregistered cloud host). You need to add a non-standard port after the URL (if you use cloudflare to build a website, you don't need to add a port, but you need to customize the source station port. You can refer to:Home data center series uses cloudflare's Origin Rules to solve the problem of having a public IP but no legal ports 80 and 443 when building a websiteThe third method is suitable for cloud hosts with a record, and the fourth method is suitable for all environments (including environments without public IP), which is also the method I recommend (regardless of whether your environment has a public IP or not, because this method does not require running https traffic directly on the public network).

4 Conclusion

1. 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, does not persist data, and only does one thing: receive HTTP requests with a specific path structure and forward the content as push notifications.

2. Client registration to obtain a unique identity (token)

Each Bark client (such as an iPhone) needs to establish a registration connection with the Bark server first, and will obtain a unique token after registration is completed.
This token is the identifier of the client, equivalent to its "address".

3. How the Webhook platform calls Bark

Any platform that supports webhook notifications can simply send a request of the following form to the Bark server:

https://your-bark-server.com/token/ Push content

As long as the request format meets the Bark agreement, the Bark server will identify the target device and forward the message content to it.

4. Server-side workflow

1. The Bark server receives the client request (i.e. webhook request)
2. Parse the token in the URI to find the currently registered and active client devices
3. Extract notification content from path and parameters
4. Construct and send push notifications to clients (e.g. via Apple Push Notification Service)

5. Why Bark is a simple webhook implementation

• Clear request structure, no authentication process required

• Use paths to distinguish target clients and avoid complex data interactions

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

• It is essentially a transit service that “matches based on URI + extracts parameter content + pushes”

Note: The summary of the last section was added later, and may seem a bit abrupt compared to the overall content, but it doesn’t matter. I think it is better to add the content of this section.