Monitoring, Logging and Troubleshooting
What this domain tests
Monitoring and troubleshooting tests how you find the cause of a production problem using LifeTime health information and Service Center logs, then fix it without weakening the environment.
Core rules
- LifeTime Environment Health gives a first view of server, database, and error indicators across environments. Use it to decide whether the issue is platform-wide or application-specific.
- Service Center is per environment. Its monitoring area exposes logs such as Error Log for unhandled exceptions, General Log for messages written with
LogMessage, Screen Log for screen execution and slowness, Scheduler Log for timers, and integration or extension logs. Filter by time, module, and user to correlate an incident. - Check timers and scheduled jobs when data is stale; a failed timer often appears in the Scheduler Log rather than the Error Log.
- Reproduce in Quality, not Production, and use the Service Studio debugger there. In Production, prefer reading logs and enabling targeted logging over attaching a debugger.
- Watch log retention: high-volume logging can fill the platform database, so tune levels and avoid logging sensitive data.
Worked example
Users report that order confirmation emails arrive late. Environment Health shows normal CPU and database load. The Scheduler Log shows the SendOrderEmails timer waking every 10 minutes and sometimes failing with a timeout. The Error Log has the same timeout stack trace. The fix is to increase the timer timeout or split the batch, not to add more LogMessage calls. After deploying to Quality and verifying, promote the tagged fix.
Traps
Checking Development logs for a Production incident; reading only the Error Log; assuming a slow screen is a code problem when it is a database query; leaving verbose logging on; and logging passwords or personal data while troubleshooting.