Log Autogrowths bigger than log size, but no shrinks to explain how
The most likely explanations I can think of are:


the database has been restored from a backup or snapshot


in the case of a restore from backup, the log file would be reverted to whatever size it was when the backup was taken
in the case of a restore from a snapshot, the log file is discarded and replaced with a tiny, 2-vlf log file

the monitoring is missing shrink events, or duplicating growth events due to a bug


the default trace event "Log File Auto Shrink" will only capture automatic shrinks.  If someone uses DBCC SHRINKFILE, it will show up as an Audit DBCC Event event.  So make sure you're capturing both



Check to see if restores are regularly occurring (for instance, if this is a test or reporting database).  Otherwise, you might need to review the code for the monitoring queries, and make sure there aren't missing or duplicated events.

One way to try and gather more information would be to use DBCC SQLPERF('LOGSPACE') to determine if the size of the log is ever changing (thanks to Paul Randal for suggesting this).  You could add this to your existing every-15-minutes check, by dumping the output into a temp table (and from there you could insert it into your logging tables):

CREATE TABLE #log_space
( 
    [DatabaseName] sysname NOT NULL,
    LogSizeMb float NOT NULL,
    LogSpaceUsedPct float NOT NULL,
    [Status] int NOT NULL
);

INSERT INTO #log_space
EXEC ('DBCC SQLPERF(LOGSPACE);');


This will help you track down whether the file ever actually grows.  If it does, now you'll know at what point in the day it's shrinking again.