Guidelines for Designing Health Rules
Applies to: SharePoint Foundation 2010
A good health rule in SharePoint Foundation has the following characteristics:
It detects a potential problem at the farm level.
Health rules are configured by farm administrators, run by farm administrators, and only farm administrators read the status reports that health rules produce. You should not use a rule to enforce a policy that does not affect the health of the farm.
It is preventative rather than diagnostic.
The rule heads off a potential problem, finds an error before it leads to trouble, or highlights a best practice. It does not troubleshoot. You should use other tools to diagnose a problem that demands immediate attention.
It monitors configuration, performance, availability, or security.
These are the built-in categories. You can create a custom category for a rule, but you should carefully examine your reasons for wanting a rule that does not fit into the existing categories. It is possible that what you want your rule to do is better suited to another tool.
It is short, straightforward, and it does not reduce availability when it runs.
Avoid placing unnecessary demands on farm resources. A health rule should not be a vehicle for resource-intensive system scans.
It does not run too often.
When you set the default automatic execution parameters for your rule, try to optimize the schedule. If the rule looks for an early sign of trouble that takes a long time to surface, do not schedule the rule for hourly or daily checks. Weekly or monthly should be sufficient.