Oxynote started as a small, slightly stubborn attempt to fix a pattern we kept running into.
In most teams, the "shape" of a code change lives in one place (requirements in Notion/Confluence), the proof that it works lives somewhere else (metrics and alerts in Grafana/Prometheus), and the reasoning ends up scattered across GitHub pull requests, chat threads, and someone’s memory. After a few weeks (or a few on-call rotations), you’re left hunting for basics: what "healthy" looks like, which edge cases matter, what the rollout plan was, who owns the service, and which runbook or decision doc this incident relates to. Docs drift quietly, metrics dashboards get tweaked quietly, and people stop trusting both.
That’s what Oxynote is for:
- A technical knowledge base for dev + infra teams, not a general wiki. It’s meant for the things engineers actually reuse: runbooks, procedures, postmortems, RFCs, architecture decisions, API contracts.
- A proper review flow for docs, closer to how code changes get reviewed. Long-form writing and rich text blocks don’t fit neatly into git-based docs, but "edit and hope" isn’t great either. Oxynote keeps the good parts of PR review without making documentation feel like another codebase to manage.
- Live metrics next to the explanation. Grafana is excellent at telling you something is happening. But Oxynote displays the metrics and helps with the why: the expected baseline, the relevant runbook, and the decisions that got you here, right next to the chart.
- Freshness hooks. If a page depends on a GitHub repo, a Docker container image tag, or an external URL, you can link it. When that source changes, Oxynote nudges you that the page (or block) might now be stale.
We’re trying to keep the whole thing intentionally simple. The goal is that you shouldn’t need a training session to use it: you open it, it behaves like you expect, and it gets out of your way.
Who we are
We’re Simon (GitHub:
swithek) and Dovydas (GitHub:
davseby) — engineers who like building tools we’d want to use ourselves.
Over the years we’ve created and contributed to a bunch of open source projects, mostly in the "make developer life less annoying" category. One example is ttlcache, an open-source in-memory data storage and caching library for Go:
https://github.com/jellydator/ttlcache. It’s used widely enough that you’ll spot it being pulled into public repos from teams like Microsoft, AWS, Datadog, and Tailscale, among many others.
Oxynote is us applying the same mindset to internal knowledge: keep it technical, keep it reviewable, keep it tied to reality.
If you want to say hello (or tell us what’s missing), you can reach us at
hello@oxynote.io