Trifle started as a frustrated developer's side project in 2015. Ten years, one WebSummit, a 3AM server meltdown, and several rewrites later, it's the metrics platform we always wished existed.
Performance monitoring sucks. That was the thought that kicked everything off.
In 2015, Jozef Vaclavik, a Ruby on Rails developer since 2007, was tired of juggling fragmented monitoring tools where one chart ended and another began with no connection between them. The data was there, scattered across dashboards that never quite answered the question you actually had.
The data was there, scattered across dashboards that never quite answered the question you actually had.
So he did what developers do: he decided to build his own.
Trifle started as a Rails plugin that hooked into ActiveSupport::Notifications to collect performance data from every request: controller actions, template rendering, database queries. The first dashboard was a proof of concept: a Rails app with some JavaScript charts. It worked. Barely.
Jozef and Lubomir, the co-founding member of the team, applied to WebSummit together and got accepted as an Alpha Startup. The conference itself was a blur, but by the end every startup walked away with $12,000 in Google Cloud credits. That bankrolled the next phase.
Processing millions of requests meant 90,000+ objects just to render a 3-hour chart. The solution: aggregate values into time-bucketed statistics. Per-minute, per-hour, per-day. MongoDB's upsert with atomic increment made writes blazingly fast. No row locks, no confirmation needed.
PerformanceHour.collection.bulk_write([{
update_many: {
filter: { app_id: id, finished_at: timestamp },
update: { '$inc' => { time: 152.33, count: 15 } },
upsert: true
}
}])This pattern, upsert with increment into time-bucketed keys, became the foundation of everything Trifle is today.
A new beta tester plugged in their scraping application at 10PM. It was a night of heavy crawling. The queue climbed to half a million, then a million, then 3.5 million jobs. Between midnight and 3AM, Jozef learned the hard way about read replicas, connection pooling, and why you don't onboard clients before bed. The queue eventually drained by lunchtime. Lesson learned: scaling is not just about spinning more servers.
When the Google Cloud credits ran out, the APM shut down. But the core idea survived. The problem was never collecting performance data. It was that the architecture tried to do too much. The next version would be simpler. Not a performance monitor. A way to answer questions from your statistical data using the database you already have.
The rewrite found its first real-world test in a hobby project: a home weather monitoring station built from Raspberry Pis with environmental sensors. Temperature, humidity, pressure, all piped into Trifle's API to collect data and build statistics. It was a small use case, but it proved the new architecture worked. Simple, composable, no fuss.
A new browser automation project needed analytics, but adopting a third-party service felt wrong. Instead, all those years of learnings were distilled into two open-source Ruby gems: Trifle::Stats for time-series metrics across Redis, PostgreSQL, and MongoDB, and Trifle::Traces for structured execution tracing. No proprietary API, just libraries you add to your app.
The same pattern, upsert with increment into time-bucketed keys, turned out to be language-agnostic. Trifle::Stats was ported to Elixir. Two languages, same simple idea, same composable approach. Learning functional programming paradigms along the way.
The libraries were always the core. But developers wanted dashboards, alerts, and a way to query metrics from the terminal. So Trifle grew into a platform: Trifle App for dashboards and automations, Trifle CLI for terminal access and AI agent integration via MCP, and a Go port of the Stats library joining Ruby and Elixir.
DropBot, a price comparison platform, uses Trifle to track 80M+ daily product price calculations with full pipeline visibility. From that 3AM queue meltdown in 2017 to production at scale. The same core idea, refined over a decade.
You don't need InfluxDB, Prometheus, or a dedicated time-series database to track business metrics. Redis, PostgreSQL, MongoDB. Pick what's already running in your stack.
The core of Trifle is open-source libraries you add to your application. Not a black-box SaaS that processes your data somewhere else. Your data stays where it is.
If it takes more than a few lines of code to start tracking something, the tool is wrong. The complexity should be in what you measure, not how you set it up.
CPU load and memory usage have plenty of tools. Trifle is for the metrics that matter to your business: orders, revenue, calculations, conversions. The things observability platforms were never designed for.
Founder & Developer
Ruby developer since 2007. Freelancer, bootstrapper, and the person behind Trifle from the first Rails plugin in 2015 to the Go implementation today. Based in Europe, building in public, shipping in evenings and weekends.
Founder & Developer
Developer since 2006 and part of the founding team from the early days. Lubomir was there when Trifle was just a Rails plugin with ambitions, joined the WebSummit pitch in 2016, and helped shape the product through its formative years. A core part of the story that got Trifle off the ground.
Trifle is bootstrapped. No venture capital, no growth-at-all-costs pressure. Just a tool built to solve a real problem, shaped by a decade of using it in production.
The Stats libraries are MIT licensed and always will be. Use them standalone, or pair them with the App and CLI for the full experience.
Whether you use the open-source libraries standalone or the full platform, you can be up and running in minutes.