Summary

• Elastic Cloud Serverless now supports cross-project search while leaving underlying observability data in its original environment.
• Dashboards, alerting, incident investigation, and service-level monitoring can operate across linked projects.
• The architecture can help organisations retain regional, organisational, or customer separation without duplicating telemetry into a central store.

Elastic has made cross-project search generally available for Elastic Cloud Serverless, allowing operations teams to investigate applications and infrastructure across separated projects without first copying their observability data into one central environment.

The capability lets queries run across linked serverless projects and can be used through dashboards, alerting, service-level objectives, and incident-management workflows. Elastic is targeting organisations that separate data by region, environment, business unit, or customer but still need a shared operational view when something fails across those boundaries.

That separation is common in large cloud estates because the tidy architecture of one observability platform often collides with data residency, organisational ownership, customer isolation, development environments, and the practical consequences of mergers or decentralised technology teams.

Centralising every log, metric, and trace can simplify querying, but it also creates duplication, network movement, storage costs, and another large concentration of sensitive operational data. Cross-project search instead leaves source information in its existing project while allowing authorised users to query it remotely.

A shared incident view without a shared data lake

The operational value becomes clearest during incidents that do not respect internal organisational boundaries. A failed application request might begin in one region, call a shared service operated by another team, and depend on infrastructure monitored through a third environment. Investigators unable to search across those systems are left moving between dashboards and reconstructing a timeline manually.

Creating a central copy of every organisation’s telemetry can generate its own problems. Observability estates grow quickly because logs and traces are produced continuously, while high-cardinality application data can turn apparently small architectural decisions into substantial storage and ingestion bills. A federated query model gives central teams another option where complete duplication is unnecessary.

The approach also fits European infrastructure decisions in which data location cannot always be treated as an incidental technical choice. Organisations may keep telemetry in particular regions because it contains customer identifiers, infrastructure details, security events, or other operational information subject to contractual and governance restrictions.

Cross-project search does not itself resolve those governance questions, because administrators still determine which projects can be linked and who is authorised to search them. It does, however, reduce the technical pressure to collapse separated datasets merely because a global operations team needs to investigate them together.

Techopia recently reported that AI deployments are widening observability gaps inside UK enterprises. As software estates become more distributed and AI services add another dependency layer, the issue is moving from whether telemetry exists towards whether the right people can correlate it quickly enough.

Observability architecture becomes data architecture

The release reflects how observability platforms have expanded beyond their original role as specialist monitoring tools. Logs, traces, metrics, profiles, security events, and service-level data now form a substantial operational dataset carrying its own questions about placement, retention, access, and cost.

A multinational organisation can therefore face the same architectural trade-offs in observability that it encounters with business data. Centralisation improves consistency and analysis but may increase movement and concentration, while decentralisation preserves local control at the expense of a shared view.

Elastic’s implementation allows central operations teams or managed-service providers to search linked projects while individual business units or customers retain distinct serverless environments. Separate development, staging, and production projects can similarly remain isolated without preventing authorised investigation across them.

The useful test will be how the feature behaves in large estates where project counts, query volumes, permissions, and data-retention policies vary substantially. Federated search reduces copying, but remote queries still consume resources and can introduce another layer of dependencies during an incident.

Administrators also need clear controls around which information becomes visible through linked projects, particularly where operational telemetry contains secrets, identifiers, or commercially sensitive detail. Distribution does not remove governance; it changes where that governance must be applied.

Cloud operations were once built around bringing every signal into a single monitoring system, whereas platforms are increasingly being asked to work across data that remains distributed for legitimate technical and organisational reasons. Cross-project search takes Elastic further towards that model.