Any Basis admin has a set of t-codes that she or he uses frequently in order to check the system's health.
Some may rely on 3rd party monitoring tools, some wait for alerts to pop-up (and some wait for the end-users to complain 
), but those who know their system well can take a glance at T-codes like SM66 and tell right away if the system is healthy.
In general, t-code SM66 (as most of you already know) shows the "Global Work Process Overview". Global - because it spans across all the app servers in a group.
It shows (for example) a snapshot of the running processes (Dialog, Spool, BTC etc.), their PID, their Status (Running\Stopped), Reason (PRIV, SLEEP, CPIC....), Time, Action (Update, Read, etc.) , User and the Table.
It also gives you memory allocation of each processes and way more.
If, for example, you see many processes running for quite some time with Reason = CPIC then you know that there is probably a problem with external interfaces that the system tries to call.
If, for example, you see many working processes updating the same table - you probably have a locking issue or any other DB issue.
If, for example you see way many processes than usual - you know that the system is working harder than usual.
I can go on and on about all of SM66' features, filters and best practices but this is not the purpose of this post.
This post holds a small and simple tip that can make a big difference:
How many times have you encountered a situation in which there was a "problem" with the system - it may have been stuck, maybe slow, even something completely vague that comes from the end users regarding a performance issue or a communication problem with external interfaces\systems - but when you try to check it - it is gone ?
Well, SM66 can't help you now because you need a retrospective look at it.
You could check the system logs for problems, STAD and so on - but you'd wish you could have taken a look at SM66 exactly at the time of the problem.
I recommend creating a simple job that will execute SAPMSM66 (this is the program sm66 runs) periodically every minute.
In case of a problem in the system which requires retrospective checks - no problem:
Just look for the job output in at the time of the problem (the spool output) - and there you have it - a snapshot
of the system's SM66 at the time of the problem.
Simple - and yet very helpful.
Enjoy 