BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//talk//9MRVPM
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-9MRVPM@programme.europython.eu
DTSTART;TZID=CET:20260716T120500
DTEND;TZID=CET:20260716T123500
DESCRIPTION:Production has a special talent for turning “seems fine” in
 to “why is everything on fire?” — usually because we’re missing si
 gnals. A service restarts and never becomes ready\, a background worker si
 lently stops consuming tasks\, or a database gets overloaded and latency c
 reeps up until downstream services (or customers) notice it first. These s
 ituations aren’t unsolvable — they’re preventable with the right sig
 nals in place.\n\nI’ve seen how stressful this gets when a system is alr
 eady in production\, but there’s no clear guidance or shared “where to
  look first” playbook\; so every incident starts with guesswork. Over ti
 me\, we turned those lessons into a lightweight standard that replaces pan
 ic mode with a predictable investigation flow.\n\nIn this talk\, I’ll sh
 are a practical\, vendor-agnostic observability checklist for a Python set
 up with three cooperating workloads: an HTTP API\, an event-driven worker\
 , and a scheduled daily job. Each workload fails differently\, so each req
 uires a different set of signals to stay observable.\n\nWe’ll cover what
  “good enough” looks like for logging\, metrics\, tracing\, and alerti
 ng: what to instrument first\, what pitfalls to avoid\, and how to design 
 alerts that catch problems early without creating noise. You’ll leave wi
 th a concrete checklist and a phased rollout order you can apply to your o
 wn Python services — without rewriting your system or committing to a sp
 ecific monitoring vendor.\n\n## **Takeaways**\n- A baseline observability 
 checklist every service should have: health/readiness\, logging with consi
 stent context\, core metrics\, and alert routing\n- Workload-specific sign
 als: what to watch in APIs vs background workers vs scheduled jobs\, and w
 hy one size doesn’t fit all\n- Structured logging that works in producti
 on: a minimal event schema + contextual fields that speed up debugging\n- 
 Must-have alerts that prevent silent failures: service never becomes ready
 \, worker stalls\, scheduled job misses its run\, sustained latency increa
 se\n- Where tracing adds value: when it’s worth the effort\, what “min
 imal viable tracing” looks like\, and what’s optional at the beginning
 \n- A rollout sequence you can apply incrementally: what to do first\, wha
 t to add later
DTSTAMP:20260524T130740Z
LOCATION:Conference Hall Complex (S4)
SUMMARY:Stop firefighting: practical observability for Python APIs\, worker
 s & jobs - Daria Korsakova
URL:https://programme.europython.eu/europython-2026/talk/9MRVPM/
END:VEVENT
END:VCALENDAR