Hi Stephen,
I think you're referring to the recovery model. It is currently set to Full recovery (so that it can be recovered from the point of failure, rather than to the point of the last backup, which is what is available under Simple recovery). I do have auto shrink on, which should truncate the log at the time of the backup. About 80 to 90% (possibly more) of the activity on my site is read-only. I believe only write or update activity constitutes a transaction, so the log should stay pretty small after each day's activities and the truncating of the log after backup.
My understanding of how these things work could be incorrect, but I have found this to be the case on my own SQL Server websites that I maintain at work. I suspect backups were not done, thus increasing the size of the log each day, unless of course, as Yash has suggested, activity on my site has increased considerably (write or update activities). I don't believe that to be the case (at least not enough to triple or quadruple the transaction log size. (The log is currently 20 MB -- up from a normal 4 to 6 MB).
As I think I mentioned earlier, I ran for quite a few months with a 10 MB limit, now it is 24 MB (60% ratio). With so little room to grow, percentage wise, I think I'll have to make the ratio 50% so my site doesn't stop functioning again, unless the "apparent" problem is corrected. My database is only 34 MB, with possibly 200 insert transactions a day.