Jonathan Almquist on Operations Manager

First, I want to say that I just realized I was getting local time.  I just changed the command to get GMT, which will be more accurate depending on your time zone and when you actually run the query.  Try running the updated query, and see if that returns the same result.

If same result... 

Alert Grooming in the database is a fairly simple process.  It simply selects alerts that have a resolution state = 255 and TimeResolved <> NULL.  Then calculates, if TimeResolved + Resolved Alert retention days = Today...groom alert.  So, if there is a problem I would first check the InternalJobHistory.

SELECT * FROM InternalJobHistory Order By InternalJobHistoryId DESC

If you see any jobs with a status code <> 1, then the job isn't starting or finishing as expected.  You could run the job manually, to see if it succeeds.  Or, check again tomorrow and see if it ran successfully.  If either results in a status code <> 1, then you'll need to do some further digging.

That's right, Nathan.  No result from the query is a good thing.  That means no alerts were "stuck" after grooming finished.  I suppose I could write some output if the command returns no data, but I'm only giving core examples here.

The reason why this needs to calculate based on GMT is because that's how the Date-Time stamp is stored in the database.  So, if you are located in GMT-6:00, for example, the query would return today's alert count if you run the command afte 7:00PM local time.  This would result in a false positive in the command results.

Now I've got to go back and fix all my other commands that use an alert field containing a Date-Time stamp in a calulation.  Arghhh...