Operations, Monitoring, and Troubleshooting
Domain 4 tests day-two operations: how to find the cause of errors and performance issues using LifeTime and Service Center, and how to interpret what each console shows.
Core rules
- LifeTime is cross-environment: it shows environment health, deployments, and application analytics across the landscape. Service Center is local to one environment and holds detailed logs, timers, integrations, and performance data.
- Error logs record runtime exceptions with module, screen or action, user, and stack details. Increase log level temporarily for diagnosis, then restore it to avoid overhead.
- Performance monitoring exposes slow screens, slow queries, and integration call timings. Use it to separate database, logic, and network causes.
- Timers run asynchronous work; a failing timer can produce repeated errors without a user-facing screen. Check timer status and next run.
- Health checks and alarms in LifeTime flag expired certificates, integration failures, and environment issues; do not wait for users to report them.
Worked example
Users report a slow checkout screen in Production. The team opens Service Center in Production, not Dev, and checks Monitoring > Performance. The screen summary shows most time in a query on Orders. They inspect the query and find a missing index on CustomerId. They add the index in Dev, test in QA, and deploy. Reasoning: LifeTime would confirm the environment and deployment history, but the detailed screen timing lives in Service Center. Using Dev logs would miss production data volume and configuration.
Traps
- Debugging production in the Development environment's Service Center.
- Leaving verbose logging on after diagnosis.
- Looking only at screen errors and missing failing timers.
- Treating LifeTime analytics as a replacement for local error logs.
- Deploying a performance fix without measuring before and after.