Infrastructure, monitoring and troubleshooting
Know the topology
A typical OutSystems 11 environment has a controller server, one or more front-end servers, and a database server. The Deployment Controller coordinates releases; the Scheduler service runs timers; the Log service writes logs asynchronously; Performance Monitoring (PM) collects runtime metrics. Front-ends run IIS/.NET or JBoss/Java depending on the stack.
Triage order
- LifeTime Environment Health for the affected environment.
- Service Center logs: Error Log first, then General, Integration, Scheduler, and Screen logs as needed.
- PM for slow screens, slow queries, integrations, and timers.
- Operating system and database tools: Event Viewer, IIS logs, app pool state, CPU/memory, database waits.
Worked example
Users report intermittent 500 errors, but only some requests fail. Environment Health shows errors rising, not flat. Service Center Error Log shows timeouts on one module. PM shows normal database time but high front-end CPU on one server. IIS logs confirm the failing requests hit a single front-end. You recycle that app pool, capture a memory dump, and scale out or fix the leak. Reasoning: intermittent errors plus per-server correlation point to a front-end fault, not a shared database fault.
Traps
- Checking only LifeTime and never opening Service Center logs.
- Assuming a load-balanced environment is homogeneous; one bad front-end can cause intermittent failures.
- Comparing timestamps across servers without timezone or NTP checks.
- Raising log verbosity and then blaming performance on the platform.