Mendix Cloud: Observability and the Runtime Engine

Mendix 11 gives you two things that matter once an app is live: a clear window into what a running application is actually doing, and a runtime engine built to do more with less. This article covers both – the OpenTelemetry-based observability stack and the leaner, faster runtime it runs on.

Observability

OpenTelemetry is the unified backbone for traces and logs. A single OpenTelemetry screen enables traces and/or logs from one place using a single endpoint for both, with tracing bundled at runtime via an OpenTelemetry Java agent and an Enable option in App Settings. Trace coverage spans all microflow activities, and span names are rich – including full XPath expressions, entity paths, object types, Java action names, and microflow names – so traces correlate cleanly with logs and metrics. Developers can create and enrich spans from Java through Core.tracing() and set attributes on already-started spans, while operators can filter spans by name and tune microflow call depth and loop iteration reporting via JVM properties.

Runtime data flows natively into major APM and SIEM tools. Mendix Cloud provides native end-to-end tracing in Datadog across apps, microflows, and cross-app actions with no custom setup, and application access logs can be forwarded to APM and SIEM tools including Splunk, Dynatrace, and New Relic for visibility into traffic patterns, authentication, and anomalies.

• Cleaner runtime logs remove noisy Broken Pipe messages and excessive exception wrapping that previously hid real errors; a UseOldExceptionBehavior=true setting restores the prior behavior for code that depended on exception nesting depth.
• A dedicated SystemTask log node surfaces system management actions, and JSON log output via tcpjsonlines supports tags and configurable trace and span IDs, with the OpenTelemetry log subscriber correctly setting the log node name and exception cause as attributes.

The runtime engine, performance, and databases

The runtime is leaner, faster, and more self-reliant. Runtime nodes automatically shut down on heartbeat failures or missing database entries to prevent orphaned nodes and improve cluster reliability, with improved cleanup of task-queue tasks owned by missing nodes. A range of performance work reduces overhead across the board: expired and anonymous sessions are cleaned up in batches to avoid out-of-memory spikes, session keep-alive and last-action-execution updates batch (with configurable batch sizes and sensible auto-derived intervals), unnecessary transaction savepoints are no longer created on multi-object commit and delete, and runtime statistics collection, session cleanup, and autocommit handling for REST calls are all faster. Object-attribute memory use is lower, workflow user associations no longer block garbage collection of non-persistable objects, and static assets – the app bundle, fonts, and app icons – are now browser-cacheable to speed up subsequent production loads.

Broad, current database and platform support. The runtime supports Oracle 23, ships an upgraded Microsoft SQL Server JDBC driver, and batches association updates when committing lists of objects. MariaDB connections must use the jdbc:mariadb: protocol prefix and defer sql_mode to the database default, and the minimum Azure SQL compatibility mode is 160 (SQL Server 2022). The bundled platform stack is kept current with Node.js 22, the .NET runtime at 10.0.7, and an upgraded ONNX dependency.

• The Rspack client bundler is available for React client apps, delivering up to 6x faster bundling and up to 70% less memory than the Rollup-based setup; Rollup remains the default and Rspack is enabled in Runtime application settings, with migration recommended.
• An opt-in MaxRetrieveAmount setting caps the number of objects a database datasource can retrieve, guarding against unbounded retrievals.
• File storage on S3 uses the AWS SDK v2 with stricter configuration handling and AES-only client-side encryption, and a FileStorage.S3.DisableChunkedEncoding setting improves compatibility with certain S3-compatible backends.
• Versions follow a clean SemVer major.minor.patch scheme – the fourth build-number element is dropped – and this is what Core.getRuntimeVersion() returns.
• The runtime fails fast on an invalid time-zone configuration by refusing to start, and task queue tasks correctly use the configured default time zone rather than UTC, can mark themselves completed after execution, and no longer increment an object’s version attribute on an unchanged commit.
• Sessions are deleted when their associated user is deleted, keeping session state consistent with the user lifecycle.

Frequently asked questions