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 metadata repository). 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 metadata repository, 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
Metadata Repository 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 metadata repository — 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 metadata repository, 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.
Studio — the unified management cockpit
One control plane for every node, tenant, user, credential, scheduled task and AI provider the platform serves. From a single authenticated session, the administrator sees the full fleet.
Server and cluster management
Every platform node registered from one interface. Cluster topology — primaries, replicas, health-check configuration — managed centrally. Adding a node to the cluster is a Studio registration; the node discovers its configuration from the configuration database. Removing a node is deregistration; the cluster redistributes read load accordingly. Node health is visible across the fleet; failed replicas are flagged and excluded from the read rotation automatically.
Identity, roles and permissions
User accounts, role assignments, authentication-mechanism configuration and multi-factor enrolment — all managed from Studio. Role changes propagate cluster-wide in milliseconds via Redis pub/sub. The same RBAC model that governs the application governs the management surface itself; administrators see what their role permits, no more.
Certificates and secrets
TLS certificate lifecycle managed centrally — issue, renew, revoke. Certificate expiry is visible in Studio before it becomes an incident. The platform's keystore surfaces secret retrieval to server-side scripts without exposing the raw secret material to application code.
Cron tasks and scheduled operations
Scheduled tasks authored, deployed and monitored from Studio. Run history, next-fire time and last-execution log are all visible in one place. Tasks are metadata-repository records; authoring is a browser interaction, not a crontab edit on a production server. Task changes propagate to the cluster without a node restart.
AI provider governance
Every AI provider registered and managed from Studio — API credentials, enabled models, per-model pricing configuration. Tenant-level spend caps and per-user request quotas set from the same surface. AI cost reporting is a query against the activity log; the Studio dashboard presents one view of that same underlying data.
Cross-tenant operations
The Studio cockpit operates across every tenant the platform hosts. Administrators see the full fleet — cluster health, active sessions, AI spend by tenant, cron task state, certificate expiry — from one session. Tenant-level filtering narrows the view; the data model is uniform across all tenants served by the installation.
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.