Direct answer

Profile while the event occurs, then look for event-dispatch calls leading into a plugin listener. High time under one listener may indicate expensive work on the tick thread; it does not prove the listener is faulty without reproducing it.

How to check it

  1. Record the Paper version, plugin versions, player count and exact event trigger (player join, inventory click, block break or movement).
  2. Run /spark profiler start --timeout 120 shortly before repeating the event, or use a longer capture if it happens infrequently.
  3. Open the report and expand the tick-thread call tree. Search plugin package names and event-dispatch/listener invocations; note the specific method and frequency.
  4. Compare a test with the event triggered versus one without. If the listener invokes database or network work synchronously, capture any accompanying stalls or errors.
  5. Reproduce on a staging server with one suspect integration disabled at a time, respecting plugin dependencies.

What to change

  • Update or reconfigure the actual plugin responsible; do not remove unrelated listeners because they share an event type.
  • Ask the plugin author about expensive handler code with a spark report and event reproduction steps.
  • If you are the developer, schedule safe I/O off-thread, but keep Bukkit world/entity API work on its required owning thread.

Software and version notes

This is aimed at Paper and compatible Bukkit-style plugins. Folia has region-thread rules and event context differences; plugins need explicit Folia-safe implementation. A profiler does not guarantee event handlers will be labeled by friendly plugin names.

Verify the result

  • Repeat the same event volume and compare the hot listener frames and MSPT.
  • Confirm event behavior still works for players, including permissions and integrations.
  • Check server logs after any plugin update or configuration change.

References