DEV Community: Jura

We put a real, live dashboard on our homepage with no signup wall. Here's how it survives strangers.

Jura — Tue, 01 Sep 2026 11:51:25 +0000

You land on a SaaS product's homepage. It looks good. You want to see the actual dashboard before you decide whether five more minutes of your life are worth a signup form. There's no way to. "Book a demo." "Start free trial" (email required, sometimes a card). A carousel of static screenshots that were true eighteen months ago. So you close the tab, and the product loses you before you ever saw the product.

We didn't want to be that tab-close. So we put a real, live, populated workspace behind a "Try live demo" button on the homepage - no email, no account, one click, straight into the actual dashboard with actual-looking data: usage charts, dead-feature detection, an events feed. Not screenshots. The real app.

The problem with that idea is the second half of the sentence: the real app, open to anyone. A dashboard is normally only as trustworthy as its access control, and we were about to hand out a session to whoever clicked a button, pointed at data other visitors are looking at too. Here's what actually had to be true before that button could ship.

"Hide the buttons" is not a security model

The lazy version of a public demo is a normal account with the delete/edit buttons hidden in the UI. It's also worthless as protection, because nothing stops a visitor from opening devtools, finding the real API call behind that hidden button, and firing it directly. UI-level restrictions are a UX feature, not an access-control boundary - they describe what a well-behaved client does, not what the server allows.

So the read-only guarantee for our demo account isn't a frontend concern at all. It's a single interceptor sitting in front of every request the backend handles, checked after auth and before any handler runs:

const SAFE_METHODS = new Set(['GET', 'HEAD', 'OPTIONS']);

@Injectable()
export class DemoReadOnlyInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<unknown> {
    const req = context.switchToHttp().getRequest<AppRequest>();

    if (req.user?.isDemoAccount && !SAFE_METHODS.has(req.method)) {
      throw new ForbiddenException('The demo account is read-only.');
    }

    return next.handle();
  }
}

It's registered globally, once, next to the app's other cross-cutting interceptor. It doesn't know or care what the request was trying to do - create a project, delete a workspace, rotate an API key, invite a teammate. If the session belongs to the demo account and the method isn't GET/HEAD/OPTIONS, it's rejected before it reaches the controller. That's the whole surface. Every mutation endpoint in the app - workspaces, projects, invites, API keys, dashboard layout, even the admin routes - is covered by one check, not by remembering to add a guard to each one individually. The alternative (annotate every mutating endpoint by hand) is exactly the kind of thing that's correct on the day you write it and silently wrong the first time someone adds a new endpoint and forgets.

isDemoAccount itself is about as small as a security check gets:

export function isDemoAccount(email?: string): boolean {
  if (!email) return false;
  return email === process.env.DEMO_ACCOUNT_EMAIL;
}

One env var, one comparison, computed once per request in the auth guard and stamped onto req.user. No table to keep in sync, no role to accidentally grant to the wrong person later.

The gap that wasn't in the interceptor - it was next to it

Here's the failure mode that actually worried us once the read-only guard existed: what if the demo account somehow also ended up with platform-admin rights? Those are two completely independent booleans, computed from two completely independent env vars (DEMO_ACCOUNT_EMAIL, PLATFORM_ADMIN_EMAIL), by two completely independent checks. Nothing links them - which is fine, until someone misconfigures one operator's environment and sets both to the same address. The read-only interceptor only blocks mutations. It says nothing about reads, and platform-admin routes are gated purely by isPlatformAdmin, not by isDemoAccount. A misconfiguration like that would hand a public, no-login-required visitor read access to internal operator tooling - workspace-wide billing internals, every customer's account list, whatever else "admin" means in a growing app.

That's not a bug you find by testing the happy path. It's a bug you find by asking "what has to be independently true for this to be safe, and is any of it actually coupled to anything else." The fix is one line, in the same place both flags get computed:

isPlatformAdmin: !demoAccount && isPlatformAdmin(session.user.email)

Demo unconditionally wins. Even if an operator someday points both env vars at the same address, the account that resolves as "demo" can never also resolve as "platform admin" - it's not a policy documented in a runbook that says "don't do that," it's a line of code that makes the mistake structurally impossible instead of merely inadvisable.

A demo that doesn't visibly rot

A demo account that never gets new data is a different kind of broken - it's harder to notice, but "last used: 4 months ago" on every feature is its own way of telling a visitor the product is dead. So the demo workspace reseeds itself every hour, on a cron, wiping and regenerating its own analytics tables (aggregates, daily/hourly stats, the raw event feed - synthesized in memory as one internally-consistent event stream, not generated table by table) so "last used" always looks like today, whatever time zone the visitor is in.

The part worth calling out isn't the cron - it's what happens if two requests hit it at once, which will happen the moment you run more than one instance of the API:

const { rows } = await lockClient.query(
  'SELECT pg_try_advisory_lock($1)',
  [LOCK_ID],
);

if (!rows[0]?.pg_try_advisory_lock) return;

A Postgres session-level advisory lock, held for the entire multi-transaction refresh. If a second instance's cron fires while the first is still mid-reseed, it just checks the lock, sees it's held, and returns immediately - no queueing, no duplicate writes, no two processes racing to regenerate the same rows. And if the reseed itself throws partway through, it's caught and logged, never rethrown - a failed tick just leaves last hour's data in place instead of leaving the demo workspace half-rewritten, and the next tick tries again.

What "done" required before this shipped

None of the above shipped on the strength of "looks right in a code review." Before we called it done:

Ran the actual seed script twice in a row against a local database and confirmed it doesn't duplicate the workspace, the projects, or double-count the current month's usage - a reseed job that isn't idempotent turns "every hour" into "growing forever."
Hit the real endpoints with a manually issued demo session cookie: GET /api/v1/auth/me (200 - reads work), POST /api/v1/workspaces (403 - mutation blocked), POST on the event-ingestion path (403 - can't be used to inject arbitrary events into the shared dataset either), GET on the analytics endpoints (200, real numbers back).
Wrote a dedicated collision test: set the demo-account env var and the platform-admin env var to the same address on purpose, and asserted the resulting session still comes back isPlatformAdmin: false. Not just "the normal case works" - the specific misconfiguration scenario, provoked deliberately.

The demo account also can't be used to bootstrap a live API key and start pushing real events into the shared workspace - there's deliberately no ProjectApiKey row created for the demo project during seeding, so there's no key for a visitor to find and copy. That one's a narrower guarantee than the interceptor (it's "we never created the door," not "the door is locked"), which is worth being honest about rather than overstating: the day a demo project would need a live key issued for some other reason, that assumption needs revisiting, not just re-trusting.

Try it

If you want to see what any of this looks like from the visitor's side rather than the request-log side: eventra.dev has a "Try live demo" link on the homepage and the sign-in page. One click, no account, into a populated workspace that's never more than an hour stale. Poke at it, try to break something - it's read-only by construction, not by convention, so go ahead.

Your feature-usage scanner doesn't know Vue, Svelte, or Astro exist. Here's how we fixed that without touching its core.

Jura — Fri, 21 Aug 2026 09:32:28 +0000

If a static analyzer only walks .ts/.tsx/.js/.jsx, every other file type isn't scanned badly - it's not scanned at all. A .vue component, a .svelte widget, an .astro page: none of them exist to the tool. Not "low confidence." Not "partial support." Invisible, the same way an empty search result looks identical whether there's genuinely nothing to find or the search just never looked in the right place.

That's exactly the gap Eventra's CLI had. It scans a codebase and tells you which tracked features are actually used - the whole pitch is "stop guessing which code is dead." Except if your team ships a Vue admin panel, a Svelte checkout widget, and an Astro marketing site around the same core app (which, if you've worked on more than one team, you've probably seen - nobody plans a multi-framework stack, it just accretes), the CLI would silently skip all three, report a clean scan, and never mention that it hadn't actually looked. The exact failure mode the product exists to prevent, happening inside the product itself.

We'd already closed this gap once, for Vue. This month we closed it for Svelte and Astro too, and the interesting part isn't the frameworks - it's that adding two more meant touching exactly zero lines of the CLI's core analysis engine.

The trick: don't teach the core anything

The CLI's core is a TypeScript-compiler-API engine: it builds a real program, walks real ASTs, resolves real symbols across files, and figures out which .track("event_name") calls are statically reachable. It is, deliberately, framework-agnostic - it doesn't know what Vue is, and it shouldn't have to.

So instead of teaching the core about .vue/.svelte/.astro, each framework gets a small, separate plugin whose only job is a translation: take the framework file, hand back one virtual TypeScript module. A Vue Checkout.vue becomes Checkout.vue.ts. A Svelte Cart.svelte becomes Cart.svelte.ts. The core never sees the original file - it sees TypeScript, because by the time it looks, that's what's actually there.

export interface CliPluginTransformResult {
  readonly modules: readonly { readonly path: string; readonly content: string }[];
}

That's most of the contract. A plugin declares which globs it wants (**/*.svelte), a match() to claim files, and a transform() that returns virtual modules. The core registers the glob, calls transform() on matching files, and feeds the result into the exact same incremental TypeScript program every .ts file goes through. No if (isVueFile) branch anywhere in the resolver, the propagation engine, or the wrapper detector. They don't know these files were ever anything but TypeScript.

The part that has to be a real compiler, not a regex

The first version of the Vue plugin - before this month - parsed .vue files with two regexes: one to grab <script> content, one to grab event="..." attributes out of <template>. It worked on every fixture, because every fixture was written to be exactly what that regex expected. It fell over on real code: dynamic bindings vanished silently, HTML comments got matched as if they were live markup, and <script> + <script setup> got concatenated with zero understanding of how Vue actually merges them.

The fix - and the standard we held Svelte and Astro to from the start - is to parse with the framework's own real compiler. Not a library that looks similar. The actual thing:

Vue: @vue/compiler-sfc, the same package Vite and Nuxt build on.
Svelte: svelte/compiler's parse(), in its documented legacy-AST mode (modern: false) - stable, tooling-oriented, and it gives you IfBlock/EachBlock/AwaitBlock as real distinct node types instead of text to pattern-match.
Astro: @astrojs/compiler, the WASM parser the Astro toolchain itself uses, which hands back a typed AST with element/component/expression nodes.

Three different compilers means three different AST shapes, and the differences turned out to matter more than expected. Svelte's legacy <script context="module"> node has no attributes field at all - recovering lang="ts" meant regex-matching the raw opening-tag text, not asking the AST for it. Astro's attribute nodes carry a kind (quoted / expression / shorthand / template-literal / …) and hand you the already-extracted expression source directly; Svelte makes you slice the original source string yourself using a MustacheTag's expression.start/.end offsets. And Astro's JSX shorthand - <Button {event} />, sugar for event={event} - leaves the attribute's .value empty for that specific kind, so the plugin has to notice the shorthand case and substitute the attribute name back in as the expression. None of that is guessable from documentation; it's the kind of thing you only find by parsing real snippets and printing the actual AST.

One convention, three parsers

Eventra's templates use a plain attribute, event="checkout.cta", to mark a tracked interaction directly in markup - no wrapper function needed for the simple case. It needed to mean the same thing in all three frameworks, expressed in whatever each one's own binding syntax actually is:

<!-- Vue -->
<button event="checkout.cta" />
<button :event="computedName" />

<!-- Svelte -->
<button event="checkout.cta" />
<button event={computedName} />

<!-- Astro -->
<button event="checkout.cta" />
<button event={computedName} />

Literal or dynamic, each plugin turns every one of these into a synthetic function call inside the virtual module - __eventra_svelte_template_event__("checkout.cta") for a literal, __eventra_svelte_template_event__(computedName) for a dynamic one, unquoted. Because it's a real call sitting in the same module scope as the actual <script>/frontmatter, a dynamic binding that happens to reference a real constant defined a few lines up gets resolved through precisely the same symbol-resolution path a plain tracker.track(someVariable) would use in any .ts file. If it can't be resolved - say, an {#each} loop variable - it's reported as a dynamic occurrence instead of silently vanishing, which was the entire bug that made the first Vue regex implementation dangerous.

The plugin declares this callee as a staticSink - { id, callee, eventNameArgumentIndex } - and the core converts that into its own internal sink detector. The plugin never imports anything from the CLI. The CLI never imports anything framework-specific. They meet in the middle through a plain data contract.

Trusting a plugin without trusting arbitrary code

eventra.json lists which plugins to load, and it's a file that gets committed to git - which means it's PR-editable by anyone who can open a pull request. If the loader did import(anyStringFromThatFile), a one-line JSON edit in a PR would be arbitrary code execution on every machine that ever runs eventra sync. The fix already existed for the Vue plugin and needed zero changes to cover the two new ones: only packages matching @eventra_dev/cli-plugin-* - an npm scope only the maintainers can publish to - are ever dynamically imported. Anything else gets skipped with a warning. Adding Svelte and Astro meant the allowlist regex, written generically the first time, just worked; the only thing that proved it was a test asserting cli-plugin-svelte matched it, written before the Svelte plugin itself existed.

Proving it actually works, not just that the unit tests pass

Unit tests for a plugin are cheap to fool - you write the fixture, you write the assertion, and if you got the mental model wrong in the same way twice, they both pass anyway. So after the plugins were built and green, we did the thing a real npm consumer would do: packed all four packages (SDK, CLI, and both new plugins) into actual .tgz tarballs with npm pack, installed them into a throwaway project exactly the way npm install would from the registry, and ran the real compiled eventra binary against a .svelte and an .astro fixture, each with one direct SDK call and one template event="..." binding.

{
  "events": [
    "astro.checkout.cta",
    "astro.checkout.started",
    "svelte.checkout.cta",
    "svelte.checkout.started"
  ]
}

Four events in, four events out, through the actual dynamic-import loading path, not a mocked one. That's the difference between "the code that implements the feature is correct" and "the feature works when a stranger installs it," and it's cheap enough to do that there's no excuse not to.

What "done" actually required

Each plugin ended up with roughly twenty tests and a hard 100% statement/branch/function/line coverage gate, and the coverage gate is what surfaced most of the interesting edge cases, not the other way around. A branch that never gets hit is either a real gap or a genuinely impossible case - and it's worth knowing which before shipping either way. A few turned out to be the second kind: svelte/compiler's attribute grammar guarantees a single-value attribute is either plain text or one expression, never a third thing, so the "neither" branch in that check is unreachable by construction, not untested by neglect. Those got a one-line comment explaining why, instead of a fabricated test pretending to exercise something the parser's own grammar rules out. The rest - a boolean-shorthand event attribute with no value, an interpolated event="a-{b}" that's neither a clean literal nor a clean expression, a context="module" script block that's present but empty - were real gaps, and each one is a case someone's actual codebase would eventually hit.

Try it

pnpm add -D @eventra_dev/cli-plugin-svelte @eventra_dev/eventra-cli
# or
pnpm add -D @eventra_dev/cli-plugin-astro @eventra_dev/eventra-cli

{
  "plugins": ["@eventra_dev/cli-plugin-svelte", "@eventra_dev/cli-plugin-astro"]
}

Same config shape as the Vue plugin, and you can list all three at once if your codebase actually is that mixed. Svelte plugin on npm · Astro plugin on npm · Vue plugin on npm · docs.

Angular's next. If your own tool has a hard-coded list of "supported" things, it's worth asking whether the boundary is actually load-bearing, or whether it's just the first three cases someone happened to write down.

Your product has features nobody uses. Here's how to find them automatically.

Jura — Tue, 16 Jun 2026 14:56:50 +0000

Eight months ago I was in a product review meeting where someone asked: "does anyone actually use the bulk export?"

Nobody knew. The PM checked Mixpanel. The event wasn't there. Someone said it might be tracked under a different name. We ended up skipping the question and moving on.

Two weeks later, the same thing happened with a different feature. Then again.

That's when I understood the real problem — and it wasn't "we need better analytics."

The actual problem isn't the data. It's the catalog.

Every analytics tool I've used works the same way: you decide what to track, you add .track() calls, data starts flowing. The tool shows you what events exist.

But what about features that were tracked under the wrong name? What about the helper function someone added six months ago that wraps the SDK — did it ever get registered in Mixpanel? What about the feature that was renamed in code but the old event name is still in the dashboard, looking alive?

You can't find dead features if you don't have a reliable catalog of what features exist.

That's the gap I kept running into. And that's what I tried to fix with Eventra.

The insight: build the catalog from the code

Instead of asking teams to manually define what they track, Eventra reads it from the TypeScript codebase itself.

The CLI uses the TypeScript compiler API to scan your project and find every eventra.track() call — including through wrapper functions, re-exports, and barrel files.

Let me show you what that means in practice.

Say you have this in your codebase:

// lib/analytics.ts
import { Eventra } from "@eventra_dev/eventra-sdk";

const sdk = new Eventra({ apiKey: process.env.EVENTRA_KEY! });

export function trackFeature(name: string, userId?: string) {
  sdk.track(name, { userId });
}

// features/export.ts
import { trackFeature } from "@/lib/analytics";

export function handleExport() {
  trackFeature("bulk_export", currentUser.id);
}

Most analytics tools would never know trackFeature wraps the SDK. You'd have to manually register it. Eventra finds the chain automatically:

npx @eventra_dev/eventra-cli sync
# Scanning...
# Found 14 events, 1 function wrapper (trackFeature → eventra.track)

It does this by building a semantic model of your code — resolving imports, following the call graph, extracting what string each name argument resolves to. Not a regex pass. The actual TypeScript compiler API.

Dead features fall out naturally

Once you have a complete, code-derived catalog, dead feature detection is trivial: which catalog entries have had no events in the last N days?

The dashboard surfaces these in a dedicated view. No configuration. No manually defining what "dead" means. The data tells you.

What's more useful is the three-state classification:

Active — at least one event in the last 14 days
Dead — had events before, nothing recently. This is your deletion list.
Never seen — in your code, never reached the platform. Misconfigured, unreachable, or behind a flag that never fires.

That third state was the one that surprised me most when I built this. Features that exist in code but have never, in the history of the product, produced a single event. Either they're behind a toggle that was never turned on, or the tracking is broken, or the feature is so buried nobody found it.

Keeping the catalog in sync: CI integration

The catalog drifts. You add a feature, forget to run sync, and now the dead feature list is incomplete. Or you remove a feature but the old name stays in the catalog, giving false confidence that something is being tracked when the code is gone.

The check command is the CI gate:

npx @eventra_dev/eventra-cli check

It compares the current state of the codebase against eventra.json (the committed catalog snapshot) and exits 1 if they differ:

Checking events and function wrappers...

Events:
+ new_feature_name   ← in code, not in catalog
- old_feature_name   ← in catalog, removed from code

Add this to your CI pipeline and the catalog never drifts without someone noticing.

The SDK side

The CLI handles catalog management. The SDK handles runtime events.

import { Eventra } from "@eventra_dev/eventra-sdk";

const eventra = new Eventra({ apiKey: "your-key" });

eventra.track("bulk_export", { userId: currentUser.id });

A few things worth mentioning about the SDK implementation that I'm happy with:

Zero dependencies. The whole thing — batching, retry with exponential backoff, circuit breaker, browser localStorage persistence, multi-tab leader election — is implemented with no runtime dependencies. Works in browser, Node.js, edge runtimes, and serverless.

Circuit breaker. After 5 consecutive delivery failures, the SDK stops sending for 5 seconds. This prevents hammering a struggling API endpoint and burning through retry budgets. When the cooldown expires, one request goes through in half-open mode. If it succeeds, the circuit closes.

Browser multi-tab coordination. If you have multiple tabs open, only one tab (the "leader") flushes events to the server. The queue is shared via localStorage and BroadcastChannel. This prevents duplicate events from tab-heavy users and reduces server load.

Graceful shutdown. In Node.js, the SDK registers SIGINT/SIGTERM handlers and flushes the queue before the process exits. In the browser, it listens to visibilitychange and pagehide. Events sent just before the user closes the tab actually arrive.

The ingest pipeline

On the server side, the bottleneck I was most worried about was write throughput. Feature events can arrive in bursts — a deploy goes out, users start using a new feature, thousands of events arrive in seconds.

The solution is PostgreSQL's COPY FROM STDIN with pg-copy-streams. Instead of individual INSERT statements, events are written to an in-memory buffer, drained in batches of up to 5,000 rows, streamed into a temp table, and atomically upserted with deduplication:

INSERT INTO analytics."FeatureEvent" (id, "projectId", ...)
SELECT t.id, t."projectId", ...
FROM tmp_events t
INNER JOIN registry_insert r
  ON r."projectId" = t."projectId"
  AND r."idempotencyKey" = t."idempotencyKey"

The IdempotencyRegistry table handles deduplication: if the SDK sends the same event twice (retry after a timeout), the second insert is a no-op. Clients use UUID v4 as the idempotency key, generated client-side.

If the database goes down, batches spill to disk (atomic tmp-rename write) and are recovered on restart. The API returns { success: true } as soon as events hit the in-memory buffer, so ingest latency stays low regardless of what the database is doing.

What I learned building this after work for 6 months

The CLI was the hardest part. The TypeScript compiler API is powerful but the documentation is thin. The wrapper propagation system — tracking which function parameter maps to the event name, across files, through re-exports — took multiple rewrites to get right. The breakthrough was treating ts.Symbol as the canonical identity and using WeakMaps keyed on symbols for all caches. Once I had that foundation, incremental watch mode fell into place.

Dead features was always the core idea. Everything else — the SDK, the dashboard, the billing, the workspaces — exists to support the dead feature detection. The catalog-from-code approach only works if there's a reliable way to discover what's in the code. The CLI is that.

Ship less is underrated as a product strategy. Every feature you remove is maintenance you never have to do, bugs that can't exist, and cognitive load you save your users. Eventra is a tool for shipping less. I find that more interesting than another tool for shipping more.

Try it

If you have a TypeScript project and want to see what's dead:

# Install the SDK
npm install @eventra_dev/eventra-sdk

# Initialize the CLI config
npx @eventra_dev/eventra-cli init

# Scan and sync
npx @eventra_dev/eventra-cli sync

Free tier is 100k events/month, no credit card.

→ eventra.dev

The SDK and CLI are MIT-licensed:

Examples:
-github.com/and-1991/eventra-examples

Happy to answer questions in the comments — especially about the static analysis approach or the ingest pipeline design.

I Built Eventra in 6 Months (After My Day Job). Here's How.

Jura — Fri, 10 Apr 2026 19:17:25 +0000

Building Eventra After Work: A 6-Month Solo Developer Journey

For the past six months, I've been building Eventra after work.

I have a full-time job that pays the bills.
Eventra is something I build in the evenings and on weekends.

I didn’t start with a startup idea.
I didn’t start with validation.
I just wanted to build something properly.

Not a weekend project.
Not a demo.
Something real.

That eventually became Eventra — a feature analytics platform focused on understanding which features users actually use.

Why I Started Building Eventra

When you build products long enough, you accumulate features.

Some are used every day.
Some occasionally.
Some… never.

Over time, you lose visibility.

You don't know:

Which features matter
Which ones nobody uses
What can be removed

Analytics helps — but only partially.

Analytics shows what happened.
But it doesn't show what exists but never happens.

That idea stuck with me.

Building After Work

Building Eventra while working full-time wasn't easy.

Some days I wrote code for 8 hours at work, then another 2–3 hours at night.

Some weekends were spent debugging rollups instead of going outside.

Progress wasn't fast — but it was steady.

Over six months, Eventra slowly took shape.

Step 1 — Building the Core Platform

I started with the core platform:

Workspaces
Projects
Events
Feature adoption
Dead feature detection
Alerts
API keys
Operations dashboard

The goal was to build something complete — not just analytics, but a system focused on feature usage.

What the Dashboard Shows

The main dashboard gives a quick overview of product usage:

Total events
Unique users
Active features
Inactive features
Usage over time

This helps quickly understand whether your product is actually being used and how feature adoption changes over time.

Feature Tracking

Eventra tracks individual features and shows:

Total usage
Unique users
First used
Last used
Usage timeline

You can open any feature and see its detailed analytics and adoption patterns.

This makes it easier to understand which parts of your product matter.

Dead Feature Detection

One of the core ideas behind Eventra is detecting unused functionality.

Eventra automatically detects features that haven't been used recently and marks them as inactive.

For example:

Feature not used in 14 days
Feature used once but never again
Feature abandoned after release

This helps identify functionality that might be safe to remove.

Events Explorer

You can also inspect raw events.

This helps when debugging or understanding how users interact with your application.

You can see:

Event name
User
Timestamp
Usage patterns

This makes it easier to understand what users actually do.

Workspaces and Projects

Eventra supports:

Multiple workspaces
Multiple projects
Team members
Permissions

This allows you to organize analytics across different products.

API Keys and SDK Integration

Each project has API keys for event ingestion.

You can rotate keys, create multiple keys, and track usage.

This allows safe integration with SDKs and backend systems.

Operations Dashboard

I also built an internal operations dashboard.

It shows:

Ingest throughput
Buffer size
Rollup lag
Processing delay
System health

This helps monitor the analytics pipeline.

Interactive Demo

There's an interactive demo on the homepage:

https://eventra.dev

You can explore the UI, navigate between pages, and see how everything works.

Some data is intentionally masked to avoid exposing real information.

This makes it possible to explore the product without signing up.

Step 2 — The SDK

Then I built the SDK.

import { Eventra } from "@eventra_dev/eventra-sdk";

const tracker = new Eventra({
  apiKey: "YOUR_PROJECT_API_KEY",
});

tracker.track("feature_used", {
  userId: "user_123",
  properties: { feature: "dashboard" }
});