The method you described sounds like it will work when the user is active online, so they would be alerted to changes that take place while they are online. That is because custom states only last as long as the user is on the page.
In terms of having a workflow run on page load to populate a list of states, which I assume is using a search of some kind could slow down your page load as the list gets large. Also, if you are not and want to keep using this method, you should put those workflows into your reusable header so you don’t forget to add it to every page.
If you want to alert a user to changes in the status field that takes place while they are offline, so that when they log in they can see an alert of any changes that took place while they were not active online, the custom state list approach wouldn’t do that.
To get that done, you’d want to take an approach similar to pushing a “read” alert in a messaging app.
Off the top of my head, I’d say you could set things up in the D.B. on your data type that has the field status to have another field “was_seen” as a yes/no, so that when a user looks at the dashboard you update the “was_seen” to yes for all items in the dashboard, then when values change in the status field, you’d set the “was_seen” to no automatically.
Also, if you want to get a bit fancier, when the user is on the dashboard when a status value changes, you would set something up to show a status of the user is on the dashboard, and then as status values change, have conditionals when saving the “was_seen” so that if the user is on the dashboard the “was_seen” is yes at the time of saving.
Then when a user logs in, you would run a search of the data field “was_seen” = no; and trigger the alert when the count is greater than zero.
This is basically the same as showing read receipts and new messages for a messaging app.