Unless you want your server to initiate some immediately-observable action at the end of the 10 minute wait while the player is offline, then there's no reason to track the timer on the server side at all.
Instead, just save a timestamp of when the button was pressed.
If the game later tries to perform an action that they're not supposed to be able to do while waiting (eg. collecting mission rewards early, or pressing the button a second time), first check the current time versus the last-pressed timestamp, and abort if the attempt is too early.
Now any realtime timer-tracking can be done in your Unity game. When you press the button, start a timer in your client-side script. When that timer completes, you know it's time to update the game state or call the server to ask for the result of the action.
If the player closes the game/browser while the timer is running, no problem: on start-up, just ask the server for any outstanding actions. It can report back the time left on any timers, or any actions that completed while you were away, and you can update the in-game state accordingly.
This helps your game scale better to large numbers of users, because your server is only ever storing/comparing/reporting data on request — it doesn't need to do any continuous background processing for every active player.
The exception is if the game action needs to trigger a result that's observable without the player running your game — like sending a push notification to their phone, or modifying the state of someone else's game who might be online now. So, to ensure your game can scale to large numbers of players, ensure you limit your use of features like this, or find ways you can process them in batches so you don't have to run independent simulations for everyone.