Hi,

There aren't tons of options...

The first thing you should check is if the agent did execute correctly every day (or at least Tuesday-Saturday based on your description), then you should check the condition query: seeing a function is one thing, what the analysis really does can be quite different. Look at what the analysis really does as query and try to identify what could make it not work correctly based on your expected behavior.

There isn't much else that can be said as it's all based on your own custom things: data, analysis, settings etc.

If they are sure (I never fully trust people: historically people lied more about things they didn't do or did wrongly than a server), maybe you have a cache issue?

If you have cache enabled your condition could have perfectly missed the updates because it never really sent a query to the database. If you have logs on you can have a chance to find out, maybe even usage tracking did capture that.

Why? Exactly because it's a prod environment you need logs to be able to analyze issues without messing around with things trying to reproduce something you don't really know what it was.

Without logs, you just have no way to investigate anything, you can only validate that the condition analysis produce a physical query matching the business rule and that you don't have anything (cache) not letting the query to be sent to the database.

Other than that you can't do anymore without logs.

You should have usage tracking enabled, mainly because it does asynchronous inserts and therefore doesn't impact your performance. That gives you already a number of information on what your prod server does (or better: what users do with it).

And yes, I would also go with log enabled. If you have a concern about logging too much and filling a disk and making you server unavailable you can enable logging and monitor the log files over a few days to best turn the rotation and retention logic of the logs.

Cache depends fully on your usage of the system: cache ON is often a quick answer to performance problems, knowing it doesn't fix anything in reality, it just does cache things. What most people do forget when enabling cache is to also fully define the rules of how to purge cache and when.

I always turn cache OFF by default and try to fix any performance issue by tuning queries etc. Then, after a bit, if the business rules are fully set and agreed by everybody (things like no intra-day loading or updates, all data always and only change once per day etc.) and there is a clear defined logic for purging the cache (like the ETL doing the data loading also call for a cache purge and refresh), cache can be safely turned ON.

People generally forget about the downsides of cache: your queries aren't hitting the database anymore if some conditions aren't met. You can update the data in the database as much as you want but cache will prevent your users from seeing it.