PlayBooks – Jupyter Notebooks style on-call investigation documents
Hello everyone, Dipesh and Siddarth here. We are building PlayBooks (https://github.com/DrDroidLab/playbooks), an open source tool to write executable notebooks for on-call investigations / remediations instead of Google Docs or Wikis. There’s a demo video here: https://www.youtube.com/watch?v=_e-wOtIm1gk, and our docs are here: https://docs.drdroid.io/docs/playbooks We were in YC’s W23 batch working on a data lakehouse with support for dynamic log schemas. Eventually we realized it was a product in search of a market and decided to…
In plain words
PlayBooks is an open source tool for on-call engineers to create executable notebooks for investigating and remediating incidents, replacing traditional Google Docs or Wikis. Built by former YC founders, it provides a Jupyter Notebooks-style interface where incident response procedures can be written, organized, and run directly within the platform. The tool is designed for development and operations teams managing on-call workflows who need a more dynamic and executable alternative to static documentation.
written from the facts on this page · September 2026
From the sources
In the maker’s words, at launch
Hello everyone, Dipesh and Siddarth here. We are building PlayBooks (https://github.com/DrDroidLab/playbooks), an open source tool to write executable notebooks for on-call investigations / remediations instead of Google Docs or Wikis. There’s a demo video here: https://www.youtube.com/watch?v=_e-wOtIm1gk, and our docs are here: https://docs.drdroid.io/docs/playbooks We were in YC’s W23 batch working on a data lakehouse with support for dynamic log schemas. Eventually we realized it was a product in search of a market and decided to stop building it. When pivoting, we decided to work on something that we originally prototyped (before even YC) but didn’t execute on. In our previous jobs, we were at a food delivery startup in India with a busy on-call routine for backend & devops engineers and a small tech team. Often business impacting issues (e.g. orders dropped by >5% in the last 15 minutes) would escalate to Dipesh as he was the lead dev who had been around for a while and he always had 4-5 hypotheses on what might have failed. To avoid becoming the bottleneck, he used to write scripts that fetched custom metrics & order related application logs every 5 minutes during peak traffic. So if an issue was reported, engineers would check the output of those scripts with all the usual suspects first, before diving into a generic exploration. This was the inspiration to get started on PlayBooks. We’ve put together a platform that can help any dev create scripts with flexibility and without requiring to code much. Our goals were: (1) it can be automated to run and send updates; (2) investigation progress can be shared easily with other team members so everyone has the right context; (3) It can all be done without being on-call or having a laptop access. Using PlayBooks, a user can configure the steps as data queries or actions within their observability stack. Here are the integrations we currently support: - Run bash commands on a remote server; - Fetch logs from AWS Cloudwatch and Azure Log Analytics; - Fetch metrics from any PromQL compatible db, AWS Cloudwatch, Datadog and New Relic; - Query PostgreSQL, ClickHouse or any other JDBC compatible databases; - Write a custom API call; - Query events from EKS / GKE; - Add an iFrame The platform focuses on not just running the tasks but also displaying information in a meaningful form with relevant graphs / logs / text outputs alongside the steps in a notebook format. Some of our users have shared feedback that on-call decision making overload has reduced with PlayBooks as relevant data from multiple tools is presented upfront in one page. Here are some of the key features that we believe will further increase the value to users looking to improve developer experience for their on-call engineers: - Automated surfacing of PlayBooks against alerts & enriching alerts with above-mentioned data; - AI-supported interpretation layer — connect with LLM or ML models to auto-analyze the data in the playbook; - Logs of historical executions to ease the effort of creating post-mortems / timelines and/or share information with peers. If this looks like something that would have been useful for you on-call or will be in your current workspace, we welcome you to try our sandbox: https://sandbox.drdroid.io/. We have added a default playbook. Just click on one of the steps in the playbook and then the “Run” button to see the playbook in action. We are excited to hear what you like about the PlayBooks and what you think could improve the oncall developer experience for your team. Please drop your comments here – we will read them eagerly and respond!
Does a similar job
all alternatives →
Airbook's Plug & Play Data Templates2023 · ▲33150+ actionable data templates with interactive SQL queries
More dev tools this month
the category →
OpenTrailPaper is open-source bike computer firmware for the LilyGO T5S3 4.7" E-Paper PRO. It supports offline maps, GPX routes, FIT recording and Bluetooth sensors.
Dev tools · 3d ago · opentrailpaper.com
Lettertrace▲375Track your AI visibility for free (using your own API keys!)
Dev tools · 26d ago · lettertrace.com
Launched alongside, June 2024
the whole month →
La Growth Machine▲1,216Create personalized, multi-channel conversations at scale
AI · 2024 · lagrowthmachine.com
PyjamaHR▲1,132Hiring on autopilot. The AI applicant tracking system (ATS).
Work · 2024 · pyjamahr.com