you can do that but I'd recommend actually timing it to see if

n/cache

is actually faster than loading the single custom record and compared against searching same. It appears NS employs some caching already, as many have noticed that subsequent runs of the same search can be much faster than the first run.

It's a good point. The config record will be searched/loaded in 4 scheduled scripts every 15 mins; I would hope the cache operation is quicker and would use less governance points than doing that search over and over again

agreed, the only downside is it's [adding n/cache] is yet another moving part. You still need some sort of load/search and now in addition we're mixing in n/cache as yet another module that can throw an UNEXPECTED_ERROR 🙂 That said, I have used n/cache quite nicely in MR scripts to smooth over the fact that different stages are executed independently, not unlike separate scripts in your scenario.