Heya! I know that Spark is meant to replace Warmroast to its most 'feature full' extent, but often enough, I end up using a timings or a /gc printout as well because spark on its own doesn't necessarily provide enough context to properly analyze the logging.

Indeed, stats like playercount would help know if normal scheduling tasks like worldsave are to be taken seriously - as its strain would vastly depend on whether playercount is high or low. Average TPS would help as well, as it would tell you whether the server is or isn't observing TPS loss. Additional items like chunk count or entity count might help big modded servers as well, for similar reasons as the playercount.

Of course, this is a suggestion and it is by no need necessary, but I thought I might as well input on what, to me, is 'missing' to fully make sense of a spark read.

Metadata is a possibility, but it would only be that.

For full TPS history in graph form, etc etc, then yes, I recommend using timings.

Oh I agree, no graph or anything of the sort, timings does not replace spark and viceversa. But having basic 'average tps' 'average playercount' can help understand the spark logging on its own, regardless of whether or not you need timings to complete the picture. Showing for instance that chunk loading is heavy would be completely relative to how many chunks are loaded during the spark, and therefore would merit from a small printout at the top, simply to help with a spark's context.

Some basic metadata has been added to the viewer output - I maintain my position from my last comment that any detail beyond this should be obtained from a timings (or similar) report instead.