Confusing title, but I couldn’t think of a better way to word it. Here’s a more clear breakdown:
In Local Monitor A, I imported some notification tones. These notification tones correctly appear under “Audio Notifications” Actions within the local monitor’s extension.
In the Web App, for any monitors with the aforementioned notification tones set, the “Audio Notification” Action would be set to “N/A” instead of the actual name (although there would be no issues with the notification sounds themselves).
When editing such a monitor from the Web App, any attempts to save it would cause the conditions to be wiped out and the “N/A” to become encased in red, as if to say “Fix this to proceed”.
So there are essentially two separate issues here:
The fact that device ringtones from a local monitor would not correctly register within the Web App, leading to an error upon attempting to edit affected monitors
The mere fact that conditions would be wiped as a result of this attempt to edit, and particularly after a “Save” action with no way to undo the damage.
In my case, this was somewhat annoying as one affected monitor used a variety of regex expressions, meaning I had to reimport it from a previous JSON backup.
@shadowmoses Thanks for the detailed report — this is very helpful.
Based on our review, here’s what’s happening:
Local audio file showing as “N/A” in the Web App
When a monitor has an audio notification configured using a custom audio file added locally, and that monitor is opened in the Cloud Watchlist Dashboard (https://monitor.distill.io/), the audio file name appears as “N/A” in the Web App.
Conditions appearing removed after saving from the Web App
If a monitor that has such a local audio notification is edited and saved from the Cloud Watchlist Dashboard, the UI may:
Show the local audio file name appearing as “N/A” is highlighted in red
Make it appear as though the monitor’s conditions were removed
However, this is only a UI display issue. The monitor’s conditions are not actually deleted on the backend.
You can confirm this by:
Closing the monitor configuration
Refreshing the Cloud Watchlist Dashboard page
Reopening the monitor configuration
The conditions should appear correctly again.
We understand how confusing this behavior can be, especially for monitors with complex conditions, and appreciate you taking the time to document it. This issue has been reported to the team so it can be addressed.
Thanks again for the detailed feedback — it helps us improve the product.
The only way to clear the red error would be to switch to a stock audio notification. Saving from here would cause the conditions to be permanently wiped (I performed your steps, but the conditions remain deleted or at least not visible.
I suppose my current workaround would be to
Leave the N/A as-is and exit out (without saving, which I can’t do anyway without changing the notification sound)
Redo whatever changes I was making via the Cloud Watchlist within the Local Device Watchlist
@shadowmoses Thanks for the clarification — and you’re absolutely right. I’ve verified this as well, and that detail is important.
To summarize the confirmed behavior and the correct guidance:
When a monitor with a local audio file is opened in the Cloud Watchlist Dashboard, the audio file may appear as “N/A”.
After making any edit and clicking Save, the UI may show:
The “N/A” local audio file highlighted in red
The monitor conditions appearing to be removed in the UI.
At this point, do not click Save again.
Clicking Save again (for example, after switching the audio from “N/A” to a stock/default tone) can result in the conditions being actually removed on the backend.
Safe workaround
Until this is fixed, please follow this approach:
If you see the “N/A” local audio highlighted in red and the conditions appear missing:
Do not click Save again
Exit/close the monitor configuration
Make any changes to such monitors from the Local Device Watchlist only, where the local audio action is handled correctly.
Keep a JSON backup before making edits, especially for monitors with complex conditions.
We’ve reported this issue with all the relevant details to the appropriate team, and they’ll be looking into it.
Thank you so much for taking the time to report this and for sharing such detailed observations — it’s been very helpful in identifying this edge case.