Observable as SQL, deployable cloud or on-prem.
Four complementary observability surfaces — MemDB (the runtime queryable as plain SQL through a standard JDBC URL), JMX (the standard JVM management surface for monitoring tools), JFR (Java Flight Recorder events for production profiling), and the enterprise activity log (every user action captured to dedicated SQL tables in the dictionary). Cluster coordination runs through Redis pub/sub; deployment runs on customer infrastructure or on cloud-ready configurations. The operator's existing analytical tooling is the operator's monitoring tooling.
Observability is a SELECT
MemDB exposes jvm, jdbc, cache, statistics and machine as in-memory SQL tables. The enterprise activity log captures every user action — logins, REST calls, DML, AI invocations, email — to dedicated SQL tables in the dictionary, queryable through any standard SQL client. SELECT * FROM jvm.memory.
JMX and JFR — standard JDK surfaces
Full JVM Management Extensions for monitoring tools (JConsole, VisualVM, any APM). Java Flight Recorder enabled in production with custom events instrumenting JDBC, connection pool and cache. The standard surfaces enterprise operators already know how to read.
Cluster coordination via Redis pub/sub
Dictionary cache invalidation propagates cluster-wide in milliseconds. Sessions in Redis (sticky optional). Stateless nodes; horizontal scaling is a property of the runtime.
Cloud or on-premises
Same supervised runtime, same architecture, both deployment models. Customer chooses the deployment topology; the platform behaves identically on either.
Observability surfaces — four complementary layers
The platform exposes its operational state through four complementary surfaces — runtime telemetry, JVM management, profiling, and a full user-action audit trail. Each is useful for a different audience; all are queryable through tools the operator already owns.
MemDB — runtime telemetry as SQL
An in-memory Instance Database at a standard JDBC URL exposes five schemas — jvm, jdbc, cache, statistics, machine — as standard SQL tables. SELECT * FROM jvm.memory. SELECT * FROM jdbc.pool_stats. Any SQL client connects; the operator's existing analytical tooling is the operator's monitoring tooling.
JMX — the standard JVM surface
Full JVM Management Extensions accessible from any JMX-aware tool (JConsole, VisualVM, your APM of choice). Memory pools, thread states, garbage-collection counters, custom application MBeans — all exposed through the standard interface enterprise operators expect.
JFR — production-grade profiling
Java Flight Recorder enabled and configurable. Continuous low-overhead recording in production, on-demand capture for specific incidents, profile-guided performance analysis through standard JFR tooling. The platform exports JFR recordings without restarting the runtime.
Activity log — every user action, captured to SQL
A built-in enterprise activity log records every user-facing action to dedicated SQL tables in the dictionary — logins, failed authentication attempts, REST API calls, microservice invocations, DML operations, report executions, AI assistant calls, outbound email, JWT and keystore operations. Deferred batch insertion (sub-microsecond add latency, in-memory queue, periodic flush) keeps the application path unblocked. Administrators query the tables directly with SQL; end-users see their own session history through the web UI. Row-scoped by user; INSERT-only by design.
Activity log — what gets recorded
Every user-facing operation is captured to a dedicated SQL table in the dictionary, indexed on user and timestamp. The full audit trail is one SQL query away — for compliance, for forensics, for cost attribution.
Authentication and sessions
Successful logins are captured with full session lifecycle — start, end, authentication method, IP address, user agent, geolocation. Failed authentication attempts are captured with the same context. The session-history view in the web UI reads this audit feed directly.
REST API and microservices
Every REST API call is captured — method, path, response time, HTTP status, request and response sizes. Internal microservice invocations are captured with operation name, duration and success flag. The platform's API surface is its own audit trail.
Data operations and execution
Every INSERT, UPDATE and DELETE is captured — operation type, target table, primary key. Report, form and grid executions are captured with timing and row count. Who changed what, when, on which row — answerable in SQL.
Security and tokens
General audit events, JWT token creation and validation, and keystore access are all captured. The cryptographic surface of the platform is logged with the same rigour as the application surface.
AI and external services
Every AI assistant interaction is captured — model name, input and output token counts, response time. Outbound email is captured with recipient, subject and delivery flag. The AI and email surfaces are queryable as plain SQL — for cost attribution, for compliance, for capacity planning.
Operations on the same platform that runs the application
Most enterprise platforms split operations across multiple tools: an APM for performance, a log aggregator for events, a separate metrics store, a vendor portal for the runtime. Each tool has its own access model, its own pricing model and its own lag. The operator paying for them rarely sees the same picture the application sees.
Airtool's operations surface runs on the same platform that runs the application. Runtime telemetry, JVM management, profiling and the full user-action audit trail are all queryable by the same SQL tools the application uses. JMX and JFR are the standard JDK surfaces every enterprise operator already knows. There is no separate plane to maintain, no separate vendor portal, and no lag between what the application is doing and what the operator can see.