[SIEM] [Detections] Stale data in Rules/Monitoring table implies Rule isn't running

[spong]

In testing the latest rules for 7.7 there was confusion around if a rule was running at its configured interval as when the page/table is not refreshed, the Last run run column will continue to update since it's being rendered as a relative date. This update seems to convey to the user that the page is refreshing data when it is not. Because of this, when the Last run time exceeds the interval that the rule runs at, it may seem to the user that the rule is failing to run or is stuck.

For example, the rules in the two tables below are configured to run every 10 minutes, but since the page hadn't been refreshed the last run dates are stale and are showing 18 minutes. This doesn't seem to be an issue on Rule Details as we don't use relative dates there and have a refresh button right next to the Last response value indicating the user must update this manually.

Possible solutions:

• Provide a Last updated at: label somewhere on the tables to show the user the last time their view has been updated
• After the Last run relative date has exceeded the Rule's run interval we switch back to just displaying the exact date as opposed to the relative date
• Don't show relative dates at all (less useful to the user)
• Provide an auto-refresh feature to ensure the data isn't stale (nice to bundle with adding a Last updated at)
  • This solves the issue full sail, but we'll need to make sure that all configuration to the table (rules per page, sorting, search query, selected groups) remains such that the users desired view stays the same between refreshes

All Rules table

Monitoring table

Rule Details

cc @elastic/security-intelligence-analytics

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[spong]

@MadameSheema this is still relevant as of the latest 7.9.0-snapshot and should be prioritized a usability enhancement as this behavior is misleading to the user.