It's probably parameter sniffing, but the documentation for sp_recompile does note that performance can drop for other reasons as well:
The queries used by stored procedures, or triggers, and user-defined functions are optimized only when they are compiled. As indexes or other changes that affect statistics are made to the database, compiled stored procedures, triggers, and user-defined functions may lose efficiency. By recompiling stored procedures and triggers that act on a table, you can reoptimize the queries.
That is not to say that some of the above things won't trigger an automatic recompile, however. In fact, most of those should trigger a recompile, which is why I wouldn't spend too much time looking down that road.
Depending on your version, enabling Query Store might make it easier to track regressions without having to manually capture plans.
Without the query plans, the stored procedure itself, etc. I would default to assuming parameter sniffing in this case until it happens again. I don't believe there is much more to talk about without more details.