Nothing you do is going to show that. A newly restored database has no performance metrics stored with it of any kind.
In order to diagnose this kind of behavior, you have to set up a capture of some kind ahead of when that behavior occurs. Assuming you're in 2008 since we're on the 2008 forum, your only choice is to set up a server side trace on the client's machine and then consume that data. If you were on 2012 or better you could use Extended Events, which are much more lightweight and offer better filtering. If you were on 2016 or better you could add in Query Store, but it's not terribly granular, so you might not see why the query ran long.
I'd also suggest getting a blocked process report set up. You could be looking at one of two situations. One, bad parameter sniffing is causing poor performance until a recompile resolves it. Two, some process is blocking the procedure, making it run long occasionally.
However, until you do these things, there's literally no way to know from where you're currently sitting. Sorry.