# GitLab Observability: Experimental → Beta Status Snapshot Status legend: ✅ done · 🟡 partial / in progress · ⬜ needs confirmation · ❌ not done · ➖ likely N/A ## The PREP workflow at a glance Three sequential steps, mapped to the templates in [`gitlab-org/architecture/readiness`](https://gitlab.com/gitlab-org/architecture/readiness): 1. **Platforms Dependency Intake** — confidential intake issue, must be approved *before* a PREP Assessment can be filed 2. **PREP Assessment issue** — tracking issue with target development stage set to `Beta` 3. **Category MRs** — up to 11 category-specific MRs (each can be marked N/A), reviewed by different teams The maturity policy requirements (opt-in defaults, exit criteria, etc.) become *evidence* you bring into the appropriate category MR. The categories are how reviewers slice the work; the policy is what the work has to satisfy. --- ## Step 1: Platforms Dependency Intake (prerequisite) - ⬜ Intake issue created and marked **confidential** - ⬜ Business metrics filled in (use AOP metrics or projection) - ⬜ Key customer impact documented - ⬜ FO impact documented - ⬜ ARR impact documented - ⬜ Dependencies enumerated with links - ⬜ Owning team defined - ⬜ Target platforms labeled — at minimum: Multi-Tenant SaaS; possibly also Self-Managed - ⬜ Target GTM date set, including Beta program timing - ⬜ Intake approved by Platforms team ## Step 2: PREP Assessment issue - ⬜ Assessment issue created in `gitlab-org/architecture/readiness` - ⬜ Overview filled: project name, epic link, owning team, target platforms, **Development Stage = Beta**, target GA date - ⬜ Business Context section filled (carry over from intake) - ⬜ Initial Assessment MR created and linked - ⬜ Relevant assessment categories identified (mark unused ones N/A) - ⬜ Stakeholder teams notified via `@team-handle` mentions - ⬜ `priority::X` label set - ⬜ `Platforms-Review::waiting` label applied ## Step 3: Category MRs For each applicable category, file an MR. The mapping below shows which maturity-policy requirements likely belong in which category. Per-category MR templates weren't included in what you shared, so the specific evidence each reviewer expects may add to what's listed here. ### Build & Release - ⬜ MR filed or marked N/A - ⬜ Configuration and dependencies are unlikely to change *(beta stability requirement)* ### Deployment - ⬜ MR filed or marked N/A - ⬜ Feature flag in place and **on by default** *(`observability_features`; confirm production default)* ### Service Architecture - ⬜ MR filed - 🟡 Tenant isolation verified — SigNoz database-per-tenant analysis exists, needs a written verification doc for reviewers - ⬜ Low risk of data loss *(EBS / ClickHouse retention story)* ### Installation & Configuration - ⬜ MR filed - ✅ Feature is disabled by default and requires explicit opt-in *(group setting `Enable Observability`)* - ✅ No path for automatic enablement *(consistent with docs; verify)* - ✅ User-facing toggle in place and **off by default** - ✅ Opt-in surface with minimal friction *(group setting, not a feature flag flip)* ### Observability - ⬜ MR filed - ⬜ SLIs mapped per the [PREP Performance Metrics Guide](https://handbook.gitlab.com/handbook/engineering/testing/prep-performance-metrics/) — ClickHouse ingest latency, query latency, etc. - ⬜ Documented, stakeholder-aligned **plan** for audit logging ### Operational Lifecycle - ⬜ MR filed - ⬜ Documented, stakeholder-aligned **plan** for security release process - ⬜ Vulnerability remediation posture documented - ⬜ Incident response test applied to known risks ### Performance & Scalability - ⬜ MR filed or deferred to GA - ⬜ SLIs mapped (overlaps with Observability category) ### Quality Assurance - ⬜ MR filed or marked N/A for Beta ### Documentation & Support - ⬜ MR filed - ❌ `Status: Beta` set in the product availability details block *(currently `Status: Experiment`)* - ❌ History entry updated to reflect the transition - ❌ Documentation language reflects beta status - ❌ Beta status reflected in the UI - 🟡 Documentation no longer claims the feature is unsupported / not ready for testing *(FAQ softens this; main docs still lead with experimental framing)* - ✅ Feedback issue created and linked from docs *(Discord + `embody-team/experimental-observability/gitlab_o11y` issue #8)* - ⬜ User experience is complete or near completion - ✅ Feature is not required or necessary for most other features ### Security & Compliance - ⬜ MR filed - ⬜ Tenant isolation verification *(cross-references Service Architecture)* - ⬜ Audit logging plan *(cross-references Observability)* - ⬜ Security release process plan *(cross-references Operational Lifecycle)* - ⬜ Consider whether a parallel [Compliance Production Readiness Assessment](https://handbook.gitlab.com/handbook/security/security-assurance/production-readiness-compliance-assessment/) is needed ### Platform Strategy - ⬜ MR filed or deferred to GA - ⬜ Target GA date defined - ⬜ Time-bound target metric for GA readiness - ⬜ Owner identified for tracking exit criteria progress --- ## Items not tied to a PREP category - ⬜ VP approval obtained for any beta requirement being skipped - ⬜ Release post drafted (optional at Beta) - ⬜ In-product discovery moment designed (optional at Beta)