Start with the incident that moved this to the top of your list

• Briefly describe the most recent production incident that prompted this evaluation.
• When did it happen and which environment or release was implicated? Options: Production, Staging, Canary, Pre-production, Other
• How long elapsed between the initial alert or user report and identifying the root cause? Options: Under 15 minutes, 15–60 minutes, 1–4 hours, Over 4 hours, Unknown
• Which telemetry sources did the on-call engineer consult, and in what order? Options: Metrics/graphing, Centralized logs, Distributed traces, APM or profiler, Infrastructure events, Other
• Who led the remediation and which teams were pulled into the incident response? Options: On-call SRE, Platform team, Service owner, Database team, Network team, Other
• Estimate the customer or business impact in failed transactions, SLA minutes, or approximate dollars for that incident.
• What single failure in your monitoring process made that incident take longer to resolve? Options: Missing correlation between traces and logs, High alert noise, Slow detection, Insufficient retention, Lack of instrumentation, Other

Where the clock actually gets eaten during an incident

• Tomorrow morning a user-facing latency spike happens, how quickly could your team trace it to the exact downstream service and log line? Options: Under 5 minutes, 5–15 minutes, 15–60 minutes, Over 60 minutes, Not reliably traceable
• How many different monitoring or observability tools must an engineer check during a typical incident? Options: 1, 2, 3, 4 or more
• Describe the last incident where tracing did not connect to the logs you needed, and state the operational consequence.
• List the manual correlation steps engineers repeat to join metrics, traces, and logs when investigating an incident. Options: Open dashboard and search logs manually, Jump between separate tracing and log UIs, Run custom queries to join data, Email or chat to find a service owner, Other
• What downstream systems fail to recover quickly when correlation is slow, and what does that cost per incident?

Pressure on cost and retention that drives decisions

• What single billing outcome over the next 12 months would force you to walk away from a new observability contract? Options: Monthly bill doubles, Cannot predict costs at scale, Retention must be cut below required window, Unexpected egress or query charges, Other
• Provide your current average monthly ingestion in gigabytes and your projected ingestion after onboarding 50 additional microservices. Options: Under 100 GB/mo, 100–500 GB/mo, 500 GB–2 TB/mo, Over 2 TB/mo, Unsure
• List the retention windows you apply today for metrics, traces, and logs in days. Options: Metrics: 7/30/90/365, Traces: 7/30/90/365, Logs: 7/30/90/365, Custom mix, Unsure
• In the last two years, how many times have you experienced a surprise spike in vendor billing after increasing instrumentation? Options: None, Once, 2–3 times, 4+ times, Not sure
• When modeling a 12-month ingestion bill at your projected volume, what planning variance would you accept for budgeting? Options: ±5%, ±10%, ±20%, More than ±20%, No tolerance

Who signs, who stalls, and how you clear gates

• Identify the single approval or stakeholder most likely to pause or block a pilot at your company. Options: Security, Legal, Procurement, Finance, Platform CTO/VP, Service owners
• Who owns API or credential access for your telemetry endpoints and integrations? Options: Platform/Infrastructure team, Security team, SRE team, Service teams, Cloud ops, Other
• State the number of full time engineers or SREs you can commit to instrumenting services and supporting the pilot. Options: 0, 1–2, 3–5, 6–10, 10+
• Do you have a documented tagging convention and a shared instrumentation library across teams? Options: Yes, both, Tagging only, Instrumentation library only, No, neither, In progress
• Estimate the calendar impact in business days if a vendor security review is required before data access is granted. Options: 0–5 days, 6–15 days, 16–30 days, Over 30 days, Unknown

The other options you and leadership are weighing

• From the options below, select which alternative you are actively evaluating or are currently using, and explain why in the free response that follows. Options: Keep current stack and extend it, Replace with another vendor, Build an internal unified solution, Combine open-source tools with internal ops, Delay decision, Other
• What would have to be true about your current approach for you to stay with it rather than change vendors?
• Has anyone on engineering leadership proposed solving unified observability internally, and if so what timeline and resourcing did they suggest? Options: Yes, with <3 month plan, Yes, with 3–6 month plan, Yes, with 6–12 month plan, No internal proposal, Unknown
• Provide the vendor proofs of concept or pilots you have run in the last 12 months and the primary outcome of each.
• Describe one shortcoming in a competing proof of value that would make you switch to a new platform immediately.

Concrete readiness and the few things that actually block rollout

• Identify the most likely integration dependency that could block a four week pilot. Options: Credential provisioning, Internal API access, Agent installation permissions, Network or firewall rules, Data residency/legal approval, Other
• Name the internal teams and API owners who must grant access to traces, logs, and metrics, and note their typical response SLA in business days.
• Rate the cleanliness and consistency of service naming and tags across teams on a scale of 1 to 5, where 5 means consistent and 1 means chaotic. Options: 1, 2, 3, 4, 5
• Select any regulatory or data residency constraints that would affect log or trace access during the pilot. Options: No constraints, SOC2/ISO required, Legal data transfer approval required, Logs must remain on-premises, Other
• Should required credentials or data access not be provided within two weeks, would the pilot be halted? Options: Yes, pilot halted, No, we will proceed with reduced scope, We would delay start, Undecided

How you will judge success and which numbers move the needle

• Would a 50 percent reduction in mean time to root cause during the pilot be sufficient to move to purchase? Options: Yes, No, Only with cost modeling, Depends on noise reduction too
• Name your top three measurable success signals for the pilot, include metric name, target, and measurement window for each.
• Which acceptance thresholds for alert noise reduction and MTTR would you require to consider the pilot successful? Options: MTTR reduction ≥30%, MTTR reduction ≥50%, Alert noise reduction ≥30%, Alert noise reduction ≥50%, Custom thresholds
• Explain the instrumentation and verification checks you will run to validate MTTR improvements and alert reduction during the pilot.
• Assuming the pilot meets all defined targets, who is authorized to sign procurement and on what timeline would you expect the purchase to complete?

If the pilot works, how fast can you move and what stands in the way

• Assuming pilot metrics meet targets, what would prevent you from signing within two weeks? Options: Legal negotiation, Procurement terms, Budget cycle timing, Security review, Internal stakeholder disagreement, Other
• Specify any legal, commercial, or procurement steps that typically add time between agreement in principle and a signed contract.
• Please name the role or team that will own migration and ongoing operational responsibilities after purchase. Options: Platform/Infra team, SRE team, Service owners, Managed services partner, Other
• Indicate the contract-level metrics or milestones you would require to trigger payment or go-live signoff. Options: MTTR target, Alert noise threshold, Ingestion cost model acceptance, Data retention promises, Other
• Will your team be prepared to start migration within 30 days if the pilot results align with targets and contract terms are standard? Options: Yes, ready in 30 days, We need 31–60 days, We need 61–90 days, Longer than 90 days, Depends on approvals

• Solution Experience, Incident Workflow Mapping

• Confirm the current state and its cost
• You confirm the demonstrated workflow identifies the root cause of a latency spike within five minutes using your telemetry.
• Provide a 30-day sample of recent incident traces, logs, and metrics for the proof replay.
• You confirm the alert correlation shown will materially reduce noisy alerts compared to your current threshold-based approach.
• Map your incident workflow to a unified view
• Run the seller cost model against the provided projected ingestion volume and deliver a 12-month cost projection before the follow-up session.
• Live proof, replay a real incident path
• You accept the seller's 12-month ingestion cost model as a realistic reflection of your projected volume, or identify specific input changes needed.
• Agree on the subset of services, success metrics, and target MTTR for the 30–60 day proof-of-value.
• Demonstrate alert correlation and noise reduction
• Provide access method details and any required onboarding checklist items for instrumenting the selected services.
• You identify any instrumentation or access gaps that must be closed before a 30–60 day proof-of-value can start.
• Validate the future state

• Solution Experience: Incident Workflow Mapping
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Deploy collectors and telemetry agents
• Instrument services for end-to-end tracing
• Onboard log pipelines and parsers
• Configure unified metrics storage and indexing
• Enable trace-to-log correlation workflows
• Implement alert engine with noise reduction
• Migrate dashboards and runbook links
• Establish tagging and instrumentation standards
• Configure retention, sampling, and ingestion caps
• Set up cost prediction and billing alerts
• Integrate incident routing and escalation
• Tune high-cardinality columnar indexing

Deploy collectors and telemetry agents

• Which host groups or Kubernetes namespaces should receive the initial collector/agent deployment (list service or namespace names, e.g., checkout-service, payments-namespace)?
• Do you require sidecar agents, node-level agents, or both for your compute environment? Options: Sidecar agents only, Node-level agents only, Both sidecar and node-level agents, Unsure; need guidance
• Who on your team will own installer access and agent credential rotation for the deployment (role or person, e.g., platform-eng lead, SRE on-call)?
• When can we schedule privileged access to a representative host or cluster for the initial install and verification (provide date range or 'next 2 weeks')? Options: Next 3 business days, Next 2 weeks, Within 1 month, Need to coordinate
• Estimate the peak expected telemetry throughput from the initial targets in MB/s or GB/day so we can size collector buffering (approximate value)
• Provide any network egress restrictions or proxy endpoints that agents must use to reach your ingestion endpoint (CIDR ranges, proxy FQDN, port)

Instrument services for end-to-end tracing

• Which services do you want instrumented for the proof-of-value trace path (explicit service names and the user-facing transaction to follow, e.g., web-frontend -> auth-service -> billing-service)?
• Do your services already emit trace context (trace-id/span-id) in outgoing requests, or will we add propagated headers to libraries and proxies? Options: Trace context is already propagated, We need to add propagation to libraries/proxies, Partial coverage, Unsure
• Who will be the code owner to accept pull requests that add tracing instrumentation to the target services (role or team)?
• When instrumenting, which span attributes or high-cardinality tags must be captured for your runbooks (for example user_id, tenant_id, request_path)?
• Identify any third-party SDKs or middleware in the call path that require special instrumentation or patching to surface distributed traces (list SDKs or middleware types)
• Specify the acceptance criterion for end-to-end tracing during PoV: can a traced user-facing latency spike be linked to the downstream service and log line within 5 minutes? Options: Yes, link within 5 minutes required, We accept a longer window for PoV, Need to discuss measurement method

Onboard log pipelines and parsers

• Which log sources and formats will be onboarded first (container stdout, syslog, application JSON logs, fluentd/forwarder streams)? Options: Container stdout, Syslog, JSON application logs, Forwarder/collector streams, Other
• Do you already have structured logging conventions (JSON fields and names) that parsers must map to, and can you attach an example log line or schema? Options: Yes, we will attach examples, No, logs are unstructured, Partial coverage
• Who on your team will maintain log parser rules and mapping definitions during the PoV (role or team)?
• When we detect new log fields that correlate to traces (for example span_id or trace_id), do you want automatic parser updates or manual approval? Options: Automatic updates, Manual approval required, Notify and recommend
• Provide the expected daily log volume from the target services in GB/day so we can size ingestion pipelines and buffering
• Indicate any compliance constraints on log storage or masking requirements (for example PCI card_number redaction, PII masking rules, HIPAA), with specific fields to redact

Configure unified metrics storage and indexing

• Which metric families and exporters are critical for the PoV (for example request_latency_ms, error_rate, cpu_usage_percent for given services)?
• Do you require custom retention tiers for different metric types (for example 90 days for SLO metrics, 14 days for debug counters)? Options: Yes, multiple retention tiers, Single retention policy, Need recommendation
• Who will own metrics naming and the mapping from your Prometheus-style metrics to the unified platform metric namespace (role or team)?
• Estimate cardinality for key metric labels we must support (for example service=checkout-service, user_id cardinality approx), expressed as approximate unique values per day
• Select the initial indexing priorities for the PoV: query latency, storage cost, or support for ad-hoc cardinality queries Options: Minimize query latency, Minimize storage cost, Support highest-cardinality queries, Balanced
• Provide an example dashboard query or SLO you want to reproduce in the platform to validate the metric model (paste the Prometheus or existing query)

Enable trace-to-log correlation workflows

• Which correlation workflow do you want validated during PoV: latency spike -> offending span -> exact log line, or error trace -> root cause log message? Options: Latency spike -> span -> log line, Error trace -> root cause log, Both
• Do your application logs already include trace identifiers (trace_id or span_id), and if so, list the exact field name used in logs Options: trace_id, span_id, traceid, No trace ids present, Other
• Who will be the reviewer to approve automated trace-to-log linker rules (role or team)?
• When correlating, do you require linking by exact trace_id match only, or by time-window plus service plus partial id (for example within 2 seconds and same request_path)? Options: Exact trace_id match, Time-window plus service, Both depending on source
• Provide the measurable acceptance criteria for trace-to-log correlation in this PoV (for example at least 90% of latency incidents must link to a log line and downstream span within 5 minutes).
• Indicate any log retention or indexing constraints that would prevent retaining the linked log lines required for correlation (for example 7-day hot logs only)

Implement alert engine with noise reduction

• Which existing alerting noise problems do you want addressed (for example N+1 alerts for pod restarts, flapping CPU thresholds, duplicate alerts across metrics and logs)?
• Do you want adaptive alerting based on baseline behavior, or rule-based suppression and deduplication, or both? Options: Adaptive baseline detection, Rule-based suppression, Both, Need recommendation
• Who manages your on-call rotation and escalation steps that alerts must integrate with (provide role or team and preferred notification targets e.g., email, webhook, pager)?
• When tuning alerts for the PoV, what noise-reduction target should we aim for (for example reduce alert volume by 40% while preserving prior incident capture rate)? Options: Reduce by 25%, Reduce by 40%, Reduce by 60%, No specific target
• Identify a sample alert from your current stack (title, condition, and typical false-positive cause) you want us to reproduce and then reduce during PoV
• Confirm the acceptance evidence for alert noise reduction: which metric will validate success (for example weekly alert count, on-call wakeups, mean time to acknowledge)? Options: Weekly alert count reduction, On-call wakeup reduction, MTTA/MTTR improvement, Custom metric

Migrate dashboards and runbook links

• Which dashboards are critical to migrate for the PoV (list by dashboard name and primary owner, e.g., Checkout SLO dashboard - payments team)?
• Do your runbooks reference specific existing queries or grafana/dashboard links that must be rewritten or preserved (attach an example runbook link or excerpt)? Options: Yes, we will attach examples, No, runbooks are generic, Partial
• Who will approve migrated dashboards and runbook link changes (role or team)?
• Select migration approach for dashboards: automated porting of queries, manual rebuilding with owner sign-off, or hybrid Options: Automated porting, Manual rebuild with owner sign-off, Hybrid
• Provide the expected update window and outage tolerance for dashboard migration (for example read-only during migration, or no disruption allowed) Options: Read-only allowed during migration, No disruption allowed, Can schedule maintenance window
• Describe any templating or variable patterns dashboards must preserve (for example $service, $environment, $region) to remain usable across teams

Establish tagging and instrumentation standards

• Which canonical tags must be present on all telemetry to support grouping and billing (for example service, environment, team, customer_tier)?
• Do you maintain a central schema or tag registry we should import, or do you want us to propose a registry based on discovered telemetry? Options: We have a registry, We need you to propose one, Partial registry exists
• Who will be the governance owner to approve tag names and prevent tag sprawl (role or team)?
• When enforcing tag standards, do you require automated blocking of noncompliant telemetry, soft enforcement with alerts, or tagging guidance only? Options: Automated blocking, Soft enforcement with alerts, Guidance only
• Provide examples of high-cardinality tags you currently use that must be preserved (for example user_id, session_id, correlation_id) and approximate cardinality
• Specify whether tag-based routing will drive ingestion caps or billing attribution during the PoV (for example cap logs from debug-tagged services) Options: Yes, tag-based caps required, No tag-based caps, Discuss further

Configure retention, sampling, and ingestion caps

• Which data classes require full-fidelity retention (for example traces for SLO incidents, security audit logs) and for how many days?
• Do you prefer server-side sampling rules by service, by environment, or adaptive sampling tied to traffic volume? Options: Service-level sampling, Environment-level sampling, Adaptive sampling based on volume, No sampling
• Who will be authorized to change retention or sampling policies during the PoV (role or team)?
• Estimate a sensible ingestion cap for the PoV (GB/day) to use as a billing projection and throttling safeguard Options: Less than 1 GB/day, 1-10 GB/day, 10-100 GB/day, More than 100 GB/day, Will provide exact estimate
• Provide the explicit acceptance condition for retention/sampling in scope (for example 30 days traces at full fidelity for priority services and 90 days for metrics)
• Indicate whether you require hard ingestion caps to block excess traffic or soft caps that alert and throttle gracefully Options: Hard cap - block ingestion, Soft cap - alert and throttle, No cap required

Set up cost prediction and billing alerts

• Provide your projected 12-month telemetry growth in terms of GB/month or percentage so we can model cost at scale
• Do you require daily cost burn-rate dashboards and alerting when projected monthly spend exceeds a threshold? Options: Yes, daily burn-rate and alerts, Weekly summaries only, Ad-hoc reports
• Who will be the billing contact who receives usage alerts and cost reports (role or email alias)?
• When projecting cost, do you want modeled scenarios for retention changes, sampled traces, and increased cardinality versus a baseline? Options: Yes, include all scenarios, Only retention and sampling, Baseline only
• Select the alert threshold style for billing notifications: absolute spend, percent-over-projection, or ingestion-rate trigger Options: Absolute spend threshold, Percent-over-projection, Ingestion-rate trigger, Combination
• Estimate the maximum acceptable monthly ingestion spend for the PoV so automated alerts can be preconfigured

• gaps
• stakeholders
• desired_state
• current_state
• decision_readiness
• success_criteria
• success_criteria
• gaps
• decision_readiness
• current_state
• stakeholders
• desired_state
• current_state
• desired_state
• success_criteria
• gaps
• stakeholders
• decision_readiness
• success_criteria
• desired_state
• current_state
• decision_readiness
• gaps
• decision_readiness
• decision_readiness
• decision_readiness

• Subscription Agreement
• Order Form
• Proof-of-Value & Success Criteria Confirmation
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Migration & Operations Addendum
• Technical & Data Access Authorization
• Change Order Agreement
• Regulatory Compliance Addendum

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate and Incumbent Wind-down (around day 90)
• Quarterly Outcome Review
• Annual Realization and Lessons Learned

• Verify that actual ingestion costs remain within acceptable variance of the modeled 12-month projection and capture corrective actions if not.
• Documented acceptance decision with pass/fail status for each numeric criterion recorded in Solution Evaluation, and a named signatory for the decision.
• A concrete incumbent wind-down plan is agreed, including data archive/migration status and decommission dates or read-only retention details.
• Publish the acceptance decision and pass/fail outcomes to the shared workspace with the named signatory and date.
• Schedule and execute the incumbent decommission or read-only retention per the agreed timeline, and confirm data migration or archive completion.
• Open remediation tickets for any failed acceptance criteria with resolution dates and publish the remediation plan.
• Trend review for MTTR and ingestion cost
• Confirm MTTR remains at or is improving toward the target recorded in Solution Evaluation, or document actions to address regressions.
• Re-confirm success criteria and owners
• Prioritize the top 3 enhancement requests for the upcoming quarter and publish the schedule.
• Open follow-up remediation work for recurring incidents with target completion dates.
• Update the cost projection and notify finance of any expected variance greater than the agreed tolerance.
• 12-month performance summary
• Confirm the achieved MTTR improvement across instrumented services compared to the baseline recorded in Solution Evaluation.
• Confirm the 12-month ingestion cost actuals and document any variance from the model recorded in Solution Evaluation with proposed adjustments.
• Publish the annual lessons learned report and update runbooks and playbooks in the shared workspace.
• Maintain the shared issue channel and confirm the triage cadence for the next 12 months.
• If required, open a billing review with finance to reconcile any cost variances identified during reconciliation.
• All critical deployment verification items are either closed or have owners with committed resolution dates.
• Onboarding status and early usage signals are documented and understood by both teams.
• Publish a deployment verification summary with outstanding items and resolution dates for the shared workspace.
• Enable missing data streams or grant required environment access to complete ingestion verification.
• Update runbooks or playbooks with any temporary workarounds identified during go-live.
• Present first 30–60 day outcomes
• Determine whether MTTR for the instrumented services is trending toward the numeric target recorded in Solution Evaluation.
• Agree a plan to reduce weekly specific alerts per service to the alert noise reduction target recorded in Solution Evaluation.
• Update the 12-month ingestion cost projection with corrected inputs and confirm any needed cost-control actions.
• Tune alert correlation rules and thresholds for the noisy alert groups identified in the review.
• Adjust instrumentation or tagging for services that could not be linked from latency spike to log line within the target time.
• Re-run the 12-month ingestion cost model with updated volume forecasts and publish the revised projection.
• Restate acceptance criteria and numeric targets
• Persistent incident and postmortem review
• Deployment verification checklist
• Present outcome data against each criterion
• Diagnose gaps against targets
• Billing reconciliation and cost variance analysis
• Document pass/fail per criterion and acceptance decision
• Early adoption and usage signals
• Operational lessons learned and runbook updates
• Agree corrective actions and timeline
• Enhancement requests and backlog prioritization
• Shared issue channel and escalation maintenance
• Incumbent system wind-down
• Confirm path to the acceptance gate
• Short operational wins and next steps
• Blockers and remediation plan
• Remediation and closure timeline for any failed criteria
• Agree next steps and schedule