Huh, this is a totally legit reason, but the solution is so horrible it shouldn't justify it. Yet I cannot come up with a "proper" way to handle this. Is there any?

At my work, all services have a "debug" HTTP port with endpoints to, among other things, dump the running configuration. But I'll admit that's less general than flags, since it depends on the server processes being built from our standard frameworks.

Also for us, we can't SSH onto hosts, and the scheduler that actually knows about args/pids/etc is fairly deep behind the curtain, but HTTP access is easy. But you could see different companies having different constraints.

A logging overlay that stores configs in a database and monitors each process. If you're testing at that scale, why would you limit yourself to what you can do with just top? To do it manually with flags and monitoring with top is very pets not cattle.

Put the config in a file and have a launcher program that turns it into flags, and then stop thinking about the flags.

That's a silly reason. At simplest, you could

a) log the entire config at startup.

or

b) create a specific file with config used, if logging is too messy.

or

c) make an API to return the running config.

or

d) use envvars in a container, that you can just dump from 'env' at will.

All of which would be cleaner and saner than browsing top.