Dispatching event to subscriber '(one of many)' takes more than 5000ms

well, I’m sort of a file-based-config orthodox so there is no mix of items or rules from files and paperui.
And yes, I’m aware that oh2 walks knee-deep through molten cheese while it’s reloading the rules-files. So I’m not surprised to see it slow down and get less responsive while that happens.
With a logInfo - line in each .rules file’s ‘when System started’ this process is visible in the openhab.log and I’m positive that this is not what I write about.

Thanks! for the curl line. 1085 items here, just for the record.

Went down your checklist, no while loop at all except 5 under automation/lib/python, no Grafana chart rendering I’m aware off (do HabPanel charts count? But I removed the ‘live’ flag from most of them as they were an obvious suspect and easily get Chromium to it’s knees.)
Which leaves me with ‘some other’.
Typical restart loops (that includes stop and start times until the last rule logs it’s init done) are 12-14 min with a 3 min pause after the initial 005_start.rules was called, included. I implemented a deferred rule loading inspired by Cleaning up the startup process / renaming rules (windows possible)

I went down the checklist Markus Storm kindly posted and linked and what i found was telegram action was still installed and telegram binding already. I fixed that. The REST documentation package binding is not installed here, does that matter?
Nothing else from that list triggered here so I fear I’ll have to get my hands dirty and enable debug logging. With regard to this, has any of you a link with info how to direct debug output into dedicated logs and not flood the openhab.log?

Thanks for your time and input, Markus and Rick!