Provider Telemetry vs Customer Telemetry

Provider telemetry and customer telemetry answer different questions. Provider telemetry tells you whether the shared platform is healthy, degraded, or under provider-led investigation. Customer telemetry tells you what identities did, what workloads accessed, what configuration changed, and whether suspicious behavior occurred inside the customer environment. Both matter, but they are not interchangeable.

This distinction matters because many teams over-trust the provider dashboard. A service health page can confirm that the platform is operating normally while a customer workload is still leaking data, using overprivileged identities, or misrouting logs. The provider can observe the shared substrate. The customer must observe the business workload and the controls wrapped around it.

The boundary usually looks like this:

    flowchart LR
	    A["Provider telemetry"] --> B["Service health, platform events, managed service faults"]
	    C["Customer telemetry"] --> D["Identity, policy, workload, and data-access events"]
	    B --> E["Shared incident picture"]
	    D --> E

What to notice:

• provider telemetry focuses on the shared platform and managed services
• customer telemetry focuses on tenant activity, configuration, workload behavior, and sensitive data access
• incident clarity usually depends on combining both views rather than mistaking one for the other

What Providers Usually Expose

Provider-managed telemetry often includes:

• service health notifications
• control-plane or managed-service status
• infrastructure fault advisories
• platform audit records that show customer-facing API activity
• provider support findings for issues inside the provider-owned layer

These signals help customers understand whether the cloud platform itself is degraded or whether a provider-side event may be contributing to the incident. They do not replace customer monitoring for business logic, user actions, or application misuse.

What Customers Must Still Enable

Customer-owned telemetry usually includes:

• workload application logs
• identity sign-in and privilege-use events
• policy and configuration change logs
• sensitive data access logs
• alerting around suspicious patterns, not just availability failures

This is the telemetry that tells the customer whether real abuse happened in the tenant, not just whether the provider platform was up.

A Practical Telemetry Coverage Map

 1telemetry_coverage:
 2  provider_signals:
 3    - service_health_advisories
 4    - managed_control_plane_status
 5    - infrastructure_incident_notices
 6  customer_signals:
 7    - identity_sign_in_logs
 8    - cloud_audit_events
 9    - workload_application_logs
10    - data_access_events_for_sensitive_stores
11    - configuration_change_events
12  owners:
13    provider_signal_review: platform-team
14    customer_signal_pipeline: security-operations
15    workload_log_quality: application-teams

What this demonstrates:

• telemetry ownership is split by layer, not by who first notices a problem
• provider signals are useful context, but customer signals are what make tenant-level detection possible
• logging quality is often shared internally across platform, security, and application teams even though it is still customer-owned overall

Why This Boundary Is Missed

Teams miss this boundary because cloud platforms expose polished dashboards and built-in monitoring tools. That can create the impression that the provider is already doing the difficult observability work. In reality, provider tooling is often a substrate for customer monitoring, not a substitute for it. If the customer never enables the right logs or never defines the right alerts, the provider has not silently taken over that responsibility.

Common Mistakes

• assuming provider health dashboards cover customer misuse, abuse, or policy drift
• enabling infrastructure metrics but skipping identity and data-access telemetry
• treating audit logs as optional because the platform is already “managed”
• failing to assign clear owners for log quality, routing, and review

Design Review Question

A team says its cloud monitoring is strong because it watches the provider service health dashboard and receives provider incident emails. The team has not enabled detailed identity logs, workload audit trails, or data-access alerts for its own environment. Is that a strong telemetry model?

No. The stronger answer is that provider telemetry helps explain the health of the shared platform, but customer telemetry is still required to detect tenant-level misuse, suspicious identities, policy drift, and workload abuse.

Check Your Understanding