There's two basic approaches to this.
First, call a script at a regular frequency to perform the work.
You can setup a Cron job that will call a given URL every so often, or at specific times throughout the day.
Your client could have a simple AJAX call that goes off if the timing is independent per player. This could even be adjusted if the player is doing something that needs more frequent checks, and then extended when they complete that task.
There are also other services that can be setup to call your scripts. For example, AWS Lambda can be scheduled to run every so often. While Lambda uses JS, Python, or Java. You could easily set something up with that to call your scripts on a regular basis. Bonus here is that if something goes wrong with your client or cron job, these should keep working.
Second, only bother checking when players request information.
Each time a player makes a request to your page, see if enough time has passed since the last check. If not, don't check.
If it has, then calculate if whatever events or timings your worried bout would have happened at that point. You control access to the data, they won't know if it was updated exactly and hour later, or three days later when they actually request it.
If you find yourself needing to make frequent updates to data, or calculations that aren't based on a players immediate interaction, it may be best to decouple your architecture.
Have your data on a separate server than your PHP scripts. This way you can have a single server handling active page requests, and then another server to perform calculations or data updates/grooming.
This of course, is also dependent on volume. I recommend start by isolating your updating code from your code that serves information out to the users. Then just go with whatever approach seems easiest to you to run that updating code, knowing that if you need to, you can always pull it out and run it somewhere else.