In terms of performance, there will be a negligable impact. Using the tick, is not inherently going to sacrifice performance, it’s how much work you do during the tick, that impacts performance. Just checking a few booleans to see what event is active, and incrementing a counter will be negligible at worst, and at best, there will be no impact at all.
So what you will be doing, or how I would code it, is that I would have one blueprint, that is external to all the code that starts/stops the events. Then hook up how you wish to notify (I would just use a function call) the recording BP for the particular event. Create one bool per event type, and when the event fires, notify the recording blueprint, and tell it the type of event, so that the bool for the event will return true. In the code that sets the bool in the recording blueprint, enable the tick at that point.
Now the tick processing will start firiring, allowing you to start the counter for that bool. When the event is done, call again to the recording to have it turn off the counting for that bool, dump out the information you wish. AFTER the bool is turned off, OR all the bools together, if it is false, then disable the tick as well.
Hence the recording blueprint, will not impact performance at all, unless there is an active event that is having the frames counted for it.
Hope this helps,