Registration Watch | Latest Release: 1.4.4 - Signed ✍ and Stable

I am delighted to announce that Registration Watch has graduated from my personal @kierknoby development space to @freepbxUK, and it has been published as a signed community module.

For anyone coming across this module for the first time, Registration Watch monitors the registration state of PJSIP extensions in FreePBX and PBXact.

It discovers configured PJSIP endpoints, shows their current registration state and useful technical details such as device and network IP addresses and ports, phone/device model information, firmware version, registration expiry, qualify interval and latency. It records registration changes over time and can send email alerts when watched registrations become unavailable and when they recover.

In practical terms, if you have remote phones or other PJSIP devices that are expected to remain registered, Registration Watch gives you somewhere to see what is registered now, what changed, when it changed, and whether an alert was sent.

It is compatible with FreePBX 16 and FreePBX 17. It will also be made available for FreePBX 18.

The module will remain open source, free to download and use, with no ads or third-party upsells.

Registration Watch 1.4.2 is the current release, published on 3rd September 2026. The module includes a FreePBX module.sig generated using my developer GPG key, which is itself signed by the FreePBX Module Signing v2 master key. This allows FreePBX to verify the integrity and provenance of the module and detect changes to the files covered by the signature.

On a correctly updated installation, Module Admin should report:

Signature Status: Good

Also new in 1.4.2

Alongside the signing milestone, 1.4.2 fixes Status History and Alert History pagination.

Previously, only the first 25 retained history records were accessible through the interface. Registration Watch now shows how many history records are retained and lets you move through them 25 records at a time. Sorting works across the entire history, not just the records currently on screen. Status History and Alert History can be browsed separately, and your sort order is saved automatically.

Normal installation and update instructions are also documented in the README.

Upgrading an older unsigned installation

During testing I identified a couple of edge cases that can affect some existing systems when moving from an older unsigned Registration Watch release to a signed version.

These concern the FreePBX module signing and key state rather than Registration Watch’s monitoring functionality, with similar third-party module signing behaviour previously discussed in Module signature warnings and Frogman is now a signed FreePBX module.

They are tracked in Issue #14 and Issue #15, and the README contains the tested troubleshooting and remediation procedures should you encounter either condition.

Source, installation, update and troubleshooting documentation:

Registration Watch remains a community module and must be updated manually for the time being, so please keep an eye on the repository or follow @freepbxUK on GitHub for future updates. If you’re using it in the real world, feedback, testing and bug reports are very welcome.

Thank you to everyone who helped me get Registration Watch to this stage. I hope you find it useful. If you like the module, please remember to :star: registrationwatch on GitHub.

Cheers,
Kieran

Thank you @kierknoby

Great work @kierknoby :smiling_face_with_sunglasses:

Thanks for sharing this module with us!

Registration Watch 1.4.3 has now been released.

This is a signed patch release fixing Email “From:” Address handling on FreePBX 17 when a display name is configured. The fix was reproduced and tested end-to-end, and the release has also been validated on FreePBX 16 and 17.

Thanks again to @JaCoTec for reporting the issue :clinking_beer_mugs:

Report issues and feedback at: Issues · freepbxUK/registrationwatch · GitHub

Solid work, sir.

Registration Watch 1.4.4 has been released :wrench:

Debounce Delay now suppresses transient failures that recover within the configured delay. Status History retains actual transitions, and Alert History records suppressed debounce decisions, including recovery notifications withheld because the corresponding problem notification was suppressed or not successfully delivered. These additional audit entries do not send emails or change recovery eligibility. Problem tracking and repeat schedules continue across Unreachable, Unknown and Not registered states. Unknown does not start a new problem alert or end an existing incident; due reminders are deferred without consuming their number until a known unhealthy state returns. Transitions into another alertable unhealthy state can still produce an initial notification when enabled, without restarting the incident’s repeat schedule.

Recovery notifications follow successful initial alerts, repeats or Storm Summaries, including recovery directly from Unknown for an existing notified incident. Duplicate and obsolete reminders are prevented, newer incident schedules are preserved during recovery cleanup, and historical replay respects completed recovery boundaries. Repeat reminders also honour their corresponding alert-type settings. Expanded regression coverage and native PDO MySQL prepared statement compatibility checks pass.

Cards/Rows highlighting now works consistently across FreePBX and PBXact. Changing the shared Show selector immediately updates the Registration Status Map.

Thanks again to @JaCoTec for reporting the Debounce issue :clinking_beer_mugs:

Report issues and feedback at: Issues · freepbxUK/registrationwatch · GitHub

This looks like a genuinely useful module, especially for setups with remote extensions where a phone can suddenly go offline without anyone noticing. I like that it tracks registration changes over time and can alert you both when a device becomes unavailable and when it recovers. The signed release is also a welcome detail for admins who need confidence in the module’s integrity. I’d be curious how much historical registration data it retains and whether alert thresholds can be customized to reduce noise from brief network interruptions. Having clear visibility into call connectivity is valuable across telecom workflows, and platforms like Phonexa also reflect the importance of reliable call data and monitoring.

Hi Dmitriy, thanks for your feedback.

The history records are lightweight and, given the use case, database growth shouldn’t normally be a concern. If a system is generating excessive history, I’d be more inclined to investigate the underlying registration instability than worry about the number of records.

Currently, there are no hard record limits built into the code. Status History and Alert History are retained indefinitely by default, with Prune settings available to keep things tidy. The interface displays 25 records per page, regardless of how many are retained.

Debounce Delay handles brief registration interruptions without generating unnecessary alerts. Configuring this individually for each extension is planned for version 1.5.x.

K