Enterprises operate different combinations of workloads across cloud, hybrid and multicloud environments. For business-critical workloads, teams need to consider monitoring and observability early so they can detect health issues, investigate failures, and understand operational impact.
Organizations place workloads on cloud platforms based on a combination of technical requirements, economics, existing dependencies, organizational standards, and business priorities. Their monitoring priorities therefore depend on what they operate and where those systems run. Those priorities will not look the same for every organization.
The Mixed Cloud Estate Reality
In my work with enterprise teams, I have seen this variation show up in the types of systems they need to observe. Some common estate components and the visibility they may require are listed below.
These patterns are not mutually exclusive. A single enterprise may operate several of them, and each may create a different observability need. They may also span hybrid or multicloud operating models, where teams need visibility across cloud boundaries, ownership, service dependencies, and operational consistency.
Common Cloud Observability Starting Points
As workloads and operational questions change, the telemetry that teams prioritize may also change.
The Starting Point Also Depends on Who Owns the Question
The starting point may also depend on who is asking the operational question. Infrastructure teams may focus first on resource health and capacity; application teams on latency, errors, and user-facing workflows; database teams on query and service performance; and security or compliance teams on access, audit activity, and configuration changes. These responsibilities vary by organization and frequently overlap, which makes shared context and telemetry correlation important.
Maturity Beyond Telemetry Checklists
Teams can easily fall into the habit of collecting as much telemetry as possible. But observability maturity is not simply the presence of metrics, logs, and traces. A team can collect all three and still struggle to answer basic operational questions. Maturity is better reflected in whether teams can detect meaningful changes, investigate issues efficiently and use telemetry to make operational decisions.
In practice, one question I often ask before suggesting an observability approach is: What workloads are you running, which operations are business-critical, and what do you need to understand when something goes wrong? The answer helps determine which telemetry and capabilities will support the team. Collecting data without a clear purpose can add cost, storage, and noise without improving diagnosis or decision-making.
How to Choose the Right Starting Point
The following questions can help an organization identify an appropriate observability starting point:
- Which cloud services and business operations are most critical?
- Which systems generate the most incidents or unanswered operational questions?
- What types of workloads does the organization operate?
- Which teams use the telemetry, and what decisions do they need to make?
- What signals already exist, and which are collected but not actionable?
- Where is diagnosis slow, and what technical or business context needs to be correlated?
Why the Foundation Still Matters for AI-Assisted Operations
AI is increasingly being used to help teams query telemetry, interpret logs, investigate alerts, and suggest next steps. In my own experience, an AI assistant can reduce the time it takes to understand a group of logs and identify likely issues. Capabilities across observability platforms now include generating queries from natural language, creating visualizations, correlating signals, and investigating alerts. More advanced use cases, such as automated investigation or approved response workflows, are also becoming part of the broader AIOps conversation.
AI assistants and agentic workflows depend on the telemetry available to them. To interpret an issue, connect related events, or recommend an action, they need relevant signals and context from the systems being operated. If that data was never collected, or if the signals cannot be correlated, the AI cannot reliably determine what happened or what should happen next.
Start with the Environment and the Question
There is no single observability starting point that fits every enterprise. The right approach depends on the systems being operated, the teams responsible for them, and the operational questions that matter most. Infrastructure metrics, logs, database signals, audit activity, application telemetry, and distributed traces can all be valuable when they help teams understand and act on what is happening. The strongest observability strategies begin with the environment teams actually operate in and the decisions their telemetry needs to support.