Last tested: May 8, 2020
This can happen if the results are the same but the order of the rows is different.
The "results changed since last run" option works by creating a hash of the results and checking that against the last run. If the order of the rows is different, even if the data itself is the same, the hash will be different and the schedule will send. The results taken into account include formatting and vis applied, so if hidden field changes, those changes alone will not cause a schedule to send.
To avoid this, the data should be sorted in a way that makes the order constant when the data is the same. If all rows are sorted on then the order will never change.
If you're seeing that schedules aren't being sent out as expected, it's possible that when Looker is "checking" it is pulling from cache rather than rerunning the query to then compare states before the send. You can confirm this by looking at the Queries panel under Admin > Queries. Theoretically at whatever time interval you set, Looker should be re-running the queries against the db to check the data.
In one case, a user was using Looker's default cache (1 hour) and used this scheduling feature to send every 5 minutes if the results are changed. However, they were only receiving it at the top of the hour and we confirmed that queries weren't being ran against the database every 5 minutes but rather being pulled from cache. Therefore we added a
persist_for at the explore level associated with the Look they were sending and it fixed it.