JTAlert Setup: Alerts, Wanted DXCC and Logging with WSJT-X
FT8 decodes arrive in a stream that no human can watch continuously. A busy band can produce dozens of lines every fifteen seconds, and somewhere in the middle of them is the one station you actually need. A correct JTAlert setup turns that stream into something manageable: it watches the decodes that WSJT-X or JTDX produces, compares each callsign with your own lists of what you still need, and tells you with a sound or a coloured highlight when it matters. It can also log the contact for you, look the operator up and push the QSO to online logbooks. This guide walks through what the program does, how to connect it, which alerts are worth enabling, how to set up automatic logging and what to check when something does not behave.
What JTAlert Does and Does Not Do
JTAlert is a companion program for Windows that listens to the decoded messages produced by WSJT-X and compatible programs such as JTDX. According to the developer’s own site at HamApps, it provides audio and visual alerts for WSJT-X and JTDX, based on the callsigns decoded. It does not decode signals itself and it does not transmit. That separation is useful to understand: the decoder keeps working exactly as before, and JTAlert is only an observer that reads what the decoder reports and reacts to it.
The alert conditions listed by the developer include your own callsign being decoded, a CQ call, a wanted callsign, and wanted prefixes, grids, US states, Canadian provinces, DXCC entities, CQ zones and continents, with the band and mode taken into account. There is also a condition for CQ Marathon entries. In other words, the program is built around the “worked before” question that every award hunter asks: do I need this one, on this band, in this mode?
It is worth saying plainly what it is not. It is not a logging program in its own right; it passes contacts to the logger you already use. It is not a replacement for a map-based tool either. If you prefer a graphical display of who is active, the article on GridTracker with WSJT-X covers that approach, and many operators run both.
Requirements and Installation
The developer’s site notes that recent versions of JTAlert are written for Windows and require the .NET 8 Desktop Runtime to be installed on the same computer. The runtime needs to be installed once, in the version that matches your operating system architecture, 64-bit or 32-bit, and Windows then keeps it updated through normal updates. The same page also warns that older Windows versions are no longer officially supported by the newest releases, and that users of those systems may need an older JTAlert release. Read the current notes on the download page before installing, because the requirements change over time and this article cannot track them.
- Install and run WSJT-X (or JTDX) first and confirm that it decodes and, if you transmit, that your radio control works. Our WSJT-X FT8 setup guide covers that.
- Install the .NET runtime if the JTAlert installer asks for it.
- Install JTAlert, start it, and let it detect the running decoder.
- Check that decodes start to appear in the JTAlert window within a cycle or two.
If JTAlert shows nothing, the usual cause is the link between the two programs. WSJT-X can send its decoded messages and status over a local network connection, and the destination must agree on both sides. Keep the defaults unless you have a reason to change them, and if you run several programs that all listen to WSJT-X, such as a map program, a logger and JTAlert, make sure they are set up to share the feed instead of competing for one connection.
Configuring Alerts That Are Actually Useful
The default temptation is to switch on every alert. The result is a tone every few seconds and a habit of ignoring all of them. A better approach is to start narrow and widen only when you are sure the signal-to-noise ratio of the alerts is acceptable.
Start With Your Own Callsign
The most valuable alert by far is a decode that contains your own callsign. A station calling you can disappear in two cycles if you do not notice, and you may be doing something else on screen. Give this alert a clear, distinct sound and keep the volume independent of the others; the developer lists independent volume and sound-file settings for each alert type, which makes that easy.
Add Wanted Callsigns and Entities
Next, define what you actually want. For an award hunter that means the DXCC entities you still need, the grids you want for a VUCC chase, or the states and provinces you need for a state award. If you are working towards a particular goal, enable only the matching alert for the bands and modes where you are actively looking. The article on awards beyond DXCC lists the common targets and which of them can be worked on FT8.
Use “Worked Before” Logic
The program flags stations you have already worked on the current band and can suppress the audio alert for them, according to the developer’s feature list. That is exactly what you want once you are past the easy contacts: no more tones for a station you already have in the log on this band. It also marks callsigns that are members of Logbook of The World or eQSL, which is useful when you want to make contacts that you can confirm electronically. The bookkeeping depends on JTAlert having an up-to-date view of your log, so scan or import your existing log once at the start.
Keep CQ Alerts Under Control
A CQ alert is useful in quiet conditions and a nuisance in busy ones. If you want to find new stations to call, enable it at low volume or only for the band you are working; otherwise leave it off and let the wanted-entity alerts do the job.
Automatic Logging
One of the biggest time savers is automatic logging. When a contact is completed in WSJT-X, JTAlert can pass it to the logger of your choice. The developer’s list of supported destinations includes DXLab DXKeeper, ACLog, Log4OM version 1 and version 2, Ham Radio Deluxe logbooks, a standard ADIF file and a MixW CSV file. The procedure is the same in every case: choose the log type in the logging settings, point JTAlert at the log or the application, and test with a single contact before relying on it.
Which destination to choose depends on what you already use. If your station is built around Log4OM or the DXLab suite, choose that application directly, so that its award tracking, lookups and uploads remain in one place. If you use a different logger, an ADIF file that your logger imports at intervals is a safe fallback. Whatever you choose, avoid logging each contact twice: only one program should be responsible for writing to the log, otherwise duplicates will appear.
Callsign Lookup and Online Logbooks
JTAlert can look up the operator’s details from an online callsign database. The developer lists QRZ.com, which is a paid subscription service for XML access, and HamQTH, which is free of charge. A lookup supplies the name, location and grid, which then appear in the log and can drive “wanted” logic for states and provinces. Enter your credentials in the lookup settings and test with a known callsign.
The program can also upload logged QSOs to online logbooks, among them QRZ.com, eQSL, Club Log and HRDLog.net, and can send decoded callsigns with frequency and signal report to HamSpots.net. Decide deliberately which of these you want. Uploading to Club Log is useful if you chase DXCC, and the automatic upload to eQSL or QRZ saves manual work, but each service needs its own credentials or API key and each has its own rules. Keep the passwords out of screenshots when you ask for help in a support group.
Alert Types at a Glance
| Alert | Best used for | Tip |
|---|---|---|
| Your callsign decoded | Never missing a reply | Distinct sound, loud enough to hear from across the room |
| Wanted callsign | A specific DX station you are waiting for | Add it only for the band and mode where you expect it |
| Wanted DXCC entity | Award hunting | Rebuild the list from your log after every big update |
| Wanted grid or state | VUCC, WAS and similar goals | Enable per band to avoid constant tones |
| CQ | Finding stations to call | Low volume, or off in busy conditions |
Combining JTAlert With Wider DX Awareness
JTAlert only sees what your own receiver decodes. If a rare station is active but not audible at your location, the program cannot warn you, and your receiver may simply be pointing the wrong way. For that wider view you need alerts that come from spots reported by other stations, which is a different mechanism from decoding your own band. The article on automating DX spot alerts from the cluster explains how those work. One tool that does this is LY4A DX Reminder, which watches five DX cluster and reporting sources and raises an alarm when a callsign you are waiting for shows up. Used together, the two approaches cover both “who is audible here” and “who is active somewhere”.
Tuning Your Setup After the First Week
An alert configuration is never finished on the first evening. After a week of use, look back at what actually happened. Which alerts made you act, and which did you ignore? An alert you consistently ignore is either set too broadly or attached to the wrong band, and it is better switched off than left to train you to disregard the sound. Conversely, if you caught yourself missing a station you wanted, find out why: perhaps the entity was on the list but for the wrong mode, or the band was not enabled for that alert.
Sound design matters more than it seems. Choose sounds that are easy to tell apart without looking at the screen: a short click for a CQ, a longer two-tone phrase for a wanted entity, and something unmistakable for your own callsign. If you share the room with others, keep the volume moderate and use headphones when you operate late at night. It also helps to review your wanted lists after each big change in your log, such as after confirmations arrive from a long-awaited DXpedition. A list that still contains entities you have already confirmed will generate alerts for contacts you no longer need, and that is the quickest way to make an alert system feel noisy and untrustworthy.
Troubleshooting a Quiet or Noisy JTAlert
- No decodes in JTAlert. Check that WSJT-X is sending decodes to the right address and port, and that no other program has grabbed the connection.
- No sound. Check that the alert has a sound file assigned, that the correct sound card is selected for JTAlert and that Windows is not muting the application.
- Wrong “worked before” flags. Rescan your log; JTAlert can only flag what it has seen in the log source it reads.
- Duplicate log entries. Only one program should write the QSO to the log. Disable the duplicate path.
- Lookup returns nothing. Verify credentials, subscription status for the paid service, and that the callsign is entered without extra characters.
The Bottom Line
A good JTAlert setup is selective. Make your own callsign the loudest alert, add only the wanted lists that match your current goal, let the “worked before” logic quiet the stations you already have, and send the contact to a single logger. Add callsign lookup and online uploads once the basics work, and remember that the program reflects what your own receiver hears. With that in place, the constant FT8 stream becomes a short list of events that deserve your attention.
Frequently Asked Questions
Does JTAlert work with JTDX as well as WSJT-X?
Yes. The developer describes JTAlert as providing audio and visual alerts for both WSJT-X and JTDX decodes.
Is JTAlert a logging program?
No. It passes completed contacts to a logger such as DXKeeper, Log4OM, ACLog or Ham Radio Deluxe, or to an ADIF file, but it does not replace them.
What do I need installed to run it?
It is a Windows application, and recent versions need the .NET 8 Desktop Runtime. Check the download page for the current requirements and the supported Windows versions.
Can it tell me when a station I need appears?
Yes, for stations your receiver decodes. You can define wanted callsigns, prefixes, grids, states, provinces, DXCC entities, CQ zones and continents, with band and mode taken into account.
Why am I not hearing any alerts?
The common causes are a broken link between the decoder and JTAlert, missing sound files for the alert, or the wrong sound card selected. Check those three first.
Does JTAlert replace a DX cluster alert tool?
No. It reacts to what your own receiver decodes. A cluster alert tool reacts to spots reported by other stations, so the two complement each other.