# The State of Observability & Reliability in the AI Era > Take the 2026 observability survey for SREs, DevOps and platform engineers: 15 short questions on incidents, alert noise, on-call and AI. Source: https://openobserve.ai/survey/ --- A 2-minute survey for SREs, DevOps and platform engineers on incidents, alert noise and AI. [Start Survey](https://openobserve.ai/survey/) ## What Does the Observability Survey Ask? Short questions for SREs and DevOps teams on the parts of incident response that cost the most time, money and sleep. ### Tool Sprawl How many tools and dashboards you switch between during an incident, where the time goes, and what your MTTR looks like. ### Alert Noise and On-Call Load Hours lost to false alarms each week, how often you are on call, and what is driving burnout on your team. ### Missed-Incident Risk How much of the alert stream you receive turns out to be real, actionable issues. ### Cost-Cutting Fallout Whether pressure to cut observability spend has reduced your logging, tracing or retention, and what that did to debugging. ### AI Adoption Where AI actually shows up in observability and incident response today, from triage and investigation to agentic tooling. ### Satisfaction and Renewal How you rate your current observability setup and which factors, from cost to open standards, drive that score. ## Survey questions ### Tool sprawl - How many separate tools/dashboards do you personally switch between during a typical incident? (0–8+ tools) - What's your team's average MTTR (mean time to resolve) for a production incident? (<30 min · 30 min–2 hrs · 2–8 hrs · 8+ hrs · Varies too much) - If you could eliminate all context-switching during incidents, by what % would your team's resolution time improve? (0–100%) ### Retention math - In a typical week, how many hours do you spend investigating alerts that turn out to be false alarms? (0–20+ hrs) - Roughly how many days a month are you on-call? (0 · 1–3 · 4–7 · 8–14 · Always) - What's the biggest driver of burnout on your team right now? (Alert volume · Tool complexity · Unclear incident ownership · Understaffed · Unclear escalation paths) ### Missed-incident risk - What share of alerts you personally receive in a typical week turn out to be real, actionable issues? (0–100%) ### Cost-cutting fallout - Have you had to reduce logging/tracing/retention because you were told to cut observability costs? (Yes, hurt debugging · Yes, no impact · No, never asked · N/A) ### AI adoption - Where are you in your AI adoption journey for observability/incident response? (Not using AI · Summarize / triage · Investigation · Actioning / auto-remediation · MCP / agentic tooling) ### Renewal risk - Overall, how satisfied are you with your current observability setup? (1 = Not at all satisfied, 5 = Extremely satisfied) - How much of a factor is each of these in that score? (rate each from 1 to 5: Cost, Reliability / uptime, Ease of use, Unified view, Integration, Vendor support, Open standards) ### About you - Which best describes your role? (SRE / Reliability · DevOps / Platform · Software engineer · Security engineer · Other) - What's your work email? - How many years of experience do you have in your current field? (<1 · 1–3 · 4–8 · 9–15 · 15+) - Roughly how many people work at your company? (<100 · 100–1,000 · 1,000–5,000 · 5,000+) ## How Is the Survey Run? - **Fielding period:** September to December 2026 - **Who responds:** SREs, DevOps and platform engineers, software engineers on call, security engineers and the people who lead those teams - **Format:** 15 questions across 7 sections, about 2 minutes. A work email is required and no name is asked for - **Reporting:** Results are published in aggregate only, broken down by role and company size. Individual responses are never published ## Observability Survey FAQ What the survey asks, who it is for and what happens to your answers. ### What is the State of Observability & Reliability survey? The State of Observability & Reliability survey is a 2026 observability survey of SREs, DevOps and platform engineers. It asks how teams detect, correlate and resolve production incidents, and what AI has changed in that work. It is run by OpenObserve, an open source (AGPL-3.0) [observability platform](/platform/) for logs, metrics and traces. ### Who should take this observability survey? It is a practitioner survey for anyone who keeps production systems reliable: SREs, DevOps and platform engineers, software engineers who carry a pager, security engineers and the people who lead those teams. You do not need to be an OpenObserve user. ### What does the survey ask about incident response? It asks how many tools you switch between during an incident, your team's typical [mean time to resolve (MTTR)](/glossary/mttr-vs-mttd/), how many hours go to false alarms each week and how much of your alert stream is actionable. It also asks where AI shows up in triage and investigation, from summaries to [AI SRE agents](/ai-sre/). ### Is the survey vendor-neutral? Yes. The questions are about your team's practices, tooling and workload in general. None of them ask about or promote a specific product, so the results reflect how SRE and DevOps teams work today, whatever stack they run. ### How long does it take? About 2 minutes. There are 15 questions across 7 short sections, and most answers are a single click or a slider. ### When does the survey close? The survey is open from September to December 2026. Once it closes, responses are combined and the findings are published as the State of Observability & Reliability report. ### Do I need to share my email? Yes, a work email is required to submit the survey. It does not ask for your name, results are only reported in aggregate and we never publish individual responses. ### What happens to my answers? Responses are combined and published as the aggregate State of Observability & Reliability report. Results are only reported in aggregate, broken down by things like role and company size, never by individual respondent. ### Where will the results be published? Once the survey closes, we publish the aggregate findings as the State of Observability & Reliability report. Follow OpenObserve on LinkedIn to see the report before anyone else. ### Can I change an answer before submitting? Yes. Use the Back button to return to any earlier section and change your answers. Nothing is sent until you press Submit on the last section.