[Initiative]: Cloud Native Observability Personas
Maintainers usually reply within 1 day
@komalRay is already working on this.
Since Sep 27, 2026.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- documentation, observability
Research direction
Start by reading the CNCF Observability Whitepaper and TAG Observability issue #42, then review the tracking document for current progress. Define the research questions and persona scope, map observability signals to each persona, and publish the reference document with the Persona/Signal Matrix as the completion criteria.
Written by the indexing model from the issue text.
Description
Name
Cloud Native Observability Personas
Short description
Develop a set of user personas pertaining to the Observability domain.
Responsible group
TAG Operational Resilience
Does the initiative belong to a subproject?
No
Subproject name
No response
Primary contact
Matt Young
Additional contacts
No response
Initiative description
Develop a comprehensive set of user personas specific to the Cloud Native Observability domain. By defining these roles—ranging from application developers debugging code to platform engineers managing fleet-wide capacity—we aim to provide a shared vocabulary for the CNCF ecosystem. This will enable project maintainers to better target their documentation and tooling, and help end-users understand which observability signals (metrics, logs, traces, profiles, …) are most relevant to their specific role and objectives.
Problem Statement As highlighted in the CNCF Observability Whitepaper, the audience for observability is multidisciplinary: Site Reliability Engineers, DevOps Engineers, Sysadmins, Software Engineers, Infrastructure Engineers, and various stakeholders all consume observability data.
However, a "one size fits all" approach to observability fails at scale. An application developer needs high-cardinality traces and profiling data to debug a specific crash, while a cluster operator needs aggregated metrics to understand capacity. Currently, the ecosystem lacks a standardized definition of these roles. This can lead to mismatched tooling, cognitive overload, and communication gaps.
In Scope
- Conduct research and interviews with the CNCF End User Community to validate real-world roles.
- Define a core set of standard personas (e.g., App Developer, SRE, Platform Engineer, IT/Compliance) relevant to cloud-native observability.
- Map specific Observability Signals (Metrics, Logs, Traces, Profiles, Dumps) to the primary needs of each persona.
- Create a "Persona Matrix" identifying the primary "Jobs to be Done" for each role within the observability lifecycle (e.g., Triage, Root Cause Analysis, Capacity Planning).
- Publish the findings.
Goals
- Establish a shared vocabulary for "Who is observing the system?" across CNCF projects.
- Provide a reference for CNCF projects to self-assess which personas their tools primarily serve.
- Help End Users identify gaps in their current observability strategy by mapping their team structures to standard personas.
- Reduce "alert fatigue" and "data overload" by curating and encouraging persona-centric dashboard and alert design patterns.
Implementation Plan
Phase 1: Research & Discovery
- Leverage the existing work started in TAG Observability Issue #42.
- Conduct structured interviews with End Users to identify challenges and wins in their current organizational structures.
- Specific questions to answer: "Who owns the alert?", "Who looks at the trace?", "Who pays the bill?"
Phase 2: Definition & Mapping
- Draft the Persona Definitions.
- The Persona/Signal Matrix: Create a mapping of signals (Metrics, Logs, Traces, Profiles) to Personas.
- Review with TAG Operational Resilience and TAG App Delivery for feedback.
Phase 3: Publication & Dissemination
- Publish the "Observability Personas" document in the TAG Observability repository.
- Present findings to the TOC and wider community (KubeCon maintainer track or similar).
- Work with CNCF projects (e.g., Prometheus, OpenTelemetry, Jaeger) to encourage adopting these persona tags in their documentation (e.g., "This guide is for [App Developers]").
Resource Requirements
- Participation from TAG Operational Resilience members for reviews.
- Access to CNCF End User community for interviews/surveys.
- Collaboration with TAG Contributor Strategy for consistent persona formatting (if applicable).
- Technical writing support (community contributions) for the final deliverable.
Timeline (draft, dependent on resourcing and level of community contribution)
- Month 1: Finalize survey/interview questions and reach out to End Users.
- Month 2-3: Conduct interviews and aggregate data.
- Month 4: Draft initial Persona definitions and Signal Matrix.
- Month 5: Community Review period.
- Month 6: Final Publication and integration into the Observability Whitepaper v1.1+.
Additional References
Deliverable(s) or exit criteria
- Publication of the "Cloud Native Observability Personas" reference document.
- A matrix mapping Observability Signals to Personas.
Tracking document for meeting and progress
- Dominant language
- HTML
- Stars
- 1.9k
- Forks
- 728
- Avg merge
- 3d 23h
- Merged PRs (30d)
- 10
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cncf/toc
-
fix(generator): correct struct tag for subproject_leads in Leadership structPossibly taken @Tharun-Varshan-S claimed this 2 days ago. Openneeds-group needs-kind needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
kind/review needs-triage review/health toc
Difficulty 5/5 Over a week Newbie friendliness 5/100
Maintainers usually reply within 1 day
-
kind/initiative needs-group needs-triage
Difficulty 5/5 Over a week Newbie friendliness 18/100
Maintainers usually reply within 1 day
-
[Initiative]: Telco AI NativePossibly taken @kashifest claimed this 7 days ago. Openkind/initiative tag/infrastructure triage/valid
Difficulty 5/5 Over a week Newbie friendliness 20/100
cncf/toc#2314 · 14 comments · 2 reactions · 1 assignee ·
Maintainers usually reply within 1 day
-
kind/initiative needs-group needs-triage
Difficulty 5/5 Over a week Newbie friendliness 30/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 Half a day Newbie friendliness 72/100
debpalash/VoiceStudio#2903 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
aws-samples/sample-per-model-bedrock#243 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 Under an hour Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
stellar/stellar-dev-skill#151 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
ajeetraina/awesome-docker-sbx#398 ·