You can use the jira:issue_updated webhook to listen for changes in issues, pull fields.customfield_12500.value from the received payload and compare it to what you have stored previously.
Don’t think on cloud there’s a way to listen for changes to a specific fields directly.
You could use both. I hear webhooks are not 100% reliable, never had it happen to our apps but other devs reported that on rare occasions webhooks were not sending changes. For a bullet proof solution what I’d do is use webhooks to listen for changes and once a day use the jql api and compare issue values with the ones you store to make sure no webhook has misfired.
It looks like Jira is close to 100% reliable in sending the webhooks, but receiving them is slightly less reliable. The unreliability is mostly vendor side, but there are network issues too (network isn’t 100% reliable) and no webhooks are retried right now. We have been asking for retries for a while and the conversation we had at App Week with the Jira Cloud Ecosystem team indicated that they were looking at it.
Is it what Atlassian says? If that is according to their stats, I think they might take into account all plugins including the old/poor/temporary/dev instances that lower down the “vendor side” metrics.
In our production instances, it is mainly Atlassian who fails to either deliver the webhook or sends it too late with expired jwt token. The jwt problem was fix recently though.
Overall, I agree that Jira is close to 100% reliable in sending webhooks but if someone needs full reliability (e.g. creating log time reports that customers rely on), the pull method mentioned by @biro is a must have.
If you need full reliability you need to use the pull method too, but that may miss deleted issues so it can be quite complex depending on your needs. If you’re expecting full reliability in any distributed system you’re going to be disappointed.