Simplified Ham Alerts on a deGoogled Phone

In my previous post I showed how to get notifications from HamAlert on a deGoogled phone. That solution requires setting up Node Red to template HamAlert spots and forward them the ntfy.

After I wrote that post, I noticed that ntfy had support to template JSON posted to it. This means that anyone with access to a ntfy server can receive HamAlert spots on their deGoogled phone without needing to set up Node Red.

If I send JSON and a template to a ntfy server.

$ curl \
    --globoff \
    --data '{"title": "SIMULATED spot N0CALL (28.420 SSB)"}' \

I get a formatted notification. I was so excited to see that there was a simpler way to get HamAlert spots on a deGoogled phone.

I tried to configure HamAlert with that URL, but at the time, HamAlert sent form data to ntfy. This is a sensible decision for HamAlert to make. Any web framework can parse form data.

Unfortunately, If I send form data to ntfy I receive an error. This is because ntfy doesn't support form data. This was sad news. I would have to get ntfy to support form data or get HamAlert to send JSON.

$ curl \
    --globoff \
    --data 'SIMULATED%20spot%20N0CALL%20%2828.420%20SSB%29' \

{"code":40042,"http":400,"error":"invalid request: message body must be JSON if templating is enabled","link":""}                        

On a whim, I posted a feature request to HamAlert's forum. I didn't expect them to add support for JSON, but today I got an email that Manuel HB9DQM had implemented support for POSTing JSON in a URL destination!

So now anyone with access to a ntfy server can receive notifications without setting up Node Red or a custom service to convert HamAlert data to a ntfy request. You can now use ntfy with a carefully constructed URL right in HamAlert.

Does this mean that you still need to set up a ntfy server for this to work? Fortunately not. You can use the public ntfy server at or the ntfy server that Christopher M0YNG set up for amateurs at While these servers are available for you to use, you might want to run your own if you can. The default IP based rate limits in ntfy may cause you to miss alerts (see the Caveat section below)


Let's start by creating a topic on your ntfy server. I am going to use the server for this example.

Visit and click "Subscribe to topic". You can put in any topic name, but make sure that it can't be guessed. If someone guesses your topic name, they can send notifications to your phone. You can click "Generate Name" if you don't care what the name is.

Next we will have to create a template for the HamAlert JSON. ntfy uses Go Templates. You can use the Go Template Playground to experiment with.

Here is an example POTA spot you can use. I will provide examples of other sources at the end of this post if you want to see how your template looks for different spot sources.

The simplest template that covers all the spot types is this template:

{{ .rawText }}

This renders a notification that looks like this. It isn't the best template for this. You can come up with a better one in the Playground

18:50 N6T in US-2838 (L.L. Stub Stewart State Park)

The hardest part of this whole thing is turning that template into a URL parameter. If you go to and paste in the template, it will produce this gnarly URL encoded string


You will want to put the URL encoded string at the end of your topic URL. Note that the 6RpjkaBXXK9SeQ48 part needs to match your topic name

So you should have this wild URL

In HamAlert, open the Destinations page and scroll to the bottom. Paste in the gnarly URL, click POST (JSON), and click save.

Open the Ham Alert simulate page , fill out the form with sample data, and click Send.

You can then see if it worked by opening the ntfy URL


One thing to consider when using publicly available ntfy servers is that they are rate-limited by IP. The default request limit per IP is pretty low. It uses a token bucket system. Each IP gets a bucket of 60 requests and the requests are refilled 1 per 5s. The result of this rate-limiting is that you will miss any spots HamAlert sends that are rate-limited.

The IP that ntfy sees is the IP of HamAlert's worker nodes. I don't know how many worker nodes HamAlert uses. If ntfy only sees one IP from HamAlert, that bucket is shared by everyone who uses this solution.

If someone configures HamAlert to spam the ntfy server, everyone using that ntfy server will not get alerts until HamAlert chills out. They may never realize that they've broken everyone's alerts because the only feedback they receive is that their alerts have stopped.

You can avoid this issue by running your own ntfy server. I would recommend that you run your own nfty server if you have the ability. That way you can tune these limits yourself.

This will also reduce the administration burden for people that have graciously hosting a public ntfy server such as Christopher M0YNG's HamAlert has the potential to spam his ntfy server and there's no de-duping of spots. If 50 people send spots to whenever Jim N4JAW rides his bike to a park, that's 50 spots sent to Christopher's ntfy server.

If you configure HamAlert to send every POTA or FT8 spot to, you may overload his server. So be careful.


This is very exciting. I love it when a complicated solution can be simplified. Thanks to Manuel HB9DQM for adding support for JSON in HamAlert URL destinations. Thanks to Christopher M0YNG for hosing a ntfy server for amateurs to use.

If you need any help setting this up, don't hesitant to reach out to me on or by email via eric at this site's domain.

Sample alert JSON

Here are some sample Ham Alert JSON packets that I captured from HamAlert itself. Each source is represented for you.


Reverse Beacon Network


DX Cluster

PSK Reporter