Dev 03 — Deployment Validation & Incident Workflows

SME Track: Developers

Presenter: Pramod Saripalli

Date: 2026-10-07

SLB × Elastic Workshop Program

Overview

Elastic-native workflows for validating service health and correlating telemetry.

Where this applies

These labs run on Observability Serverless — a fully managed project so you can practice without cluster operations.

The same capabilities you explore here — ES|QL, Streams, AI Assistant, Agent Builder, Workflows, and SLOs — are available on Elastic Cloud Hosted (ECH) and self-managed deployments.

Serverless mainly saves operational toil (sizing, ILM, Fleet, upgrades). Your observability skills transfer directly.

Session topics

  • Service health checks after deployments
  • Correlating telemetry sources (logs, metrics, traces)
  • Saved queries and views for daily use

Why these features?

Unified ObservabilityLogs, metrics, and traces in one place
ES|QLOne query language for logs, metrics, and traces
SLOsUser-facing reliability, not just green dashboards
🔔Observability AlertsSignal without the noise

Use → to see why each feature matters for SLB.

Why Unified Observability?

Logs, metrics, and traces in one place

Without it

Three tabs, three tools, manual correlation — "which deploy caused this spike?" takes too long.

With Unified Observability

APM, Logs Explorer, and Metrics views link the same service context — pivot from error log to trace to CPU in clicks.

  • Shorter MTTR when signals share service.name and trace.id
  • Deploy validation: check all three pillars after a release
  • One Observability overview for leadership and SRE review
Logs
Metrics
Traces

Why ES|QL?

One query language for logs, metrics, and traces

Without it

Different syntax per signal — PromQL for metrics, LogQL for logs, trace UI only — context switching slows incidents.

With ES|QL

ES|QL pipes data through filters, stats, and joins across observability datasets in Logs Explorer and Dev Tools.

  • Faster investigations with reusable query patterns
  • Same syntax in Logs Explorer on Serverless, ECH, and self-managed
  • AI Assistant can draft and explain ES|QL for your team
FROM logs-*
STATS / WHERE
Answer

Why SLOs?

User-facing reliability, not just green dashboards

Without it

CPU graphs look fine while customers see errors — no shared error budget or burn-rate language with product teams.

With SLOs

SLOs define availability/latency targets from real traces and metrics, with burn alerts before users flood support.

  • Align SRE and product on measurable reliability
  • Prioritize fixes when error budget is draining
  • Native in Observability on every deployment — no custom PromQL recording rules required
SLI signal
SLO target
Burn alert

Why Observability Alerts?

Signal without the noise

Without it

Alert storms, duplicate pages, and rules that never get tuned — on-call learns to ignore the channel.

With Observability Alerts

Threshold, anomaly, and SLO-based rules with grouping, suppression, and AI-assisted triage in one alerts UI.

  • Tune rules to SLB services instead of one-size-fits-all thresholds
  • Deduplicate and acknowledge with context for handoffs
  • Feed Workflows for automated first response
Rule
Alert
Triage

Hands-on lab

Your lab uses Elastic Observability Serverless for a zero-ops learning environment.

The steps and features are the same on ECH and on-prem — follow the assignment panel when Kibana opens.

Instruqt track: slb-sme-developers

Resources

  • Registration: events.elastic.co/slbworkshops
  • Repo: github.com/poulsbopete/slb-workshops
  • Use ← → arrow keys to navigate slides