How Tindra Works - Error Tracking and Performance Monitoring

Catch errors, understand them, resolve them.

Every unhandled exception, every caught error you forward, lands in the issue list grouped by fingerprint. Tindra deduplicates intelligently so your team works on unique problems, not thousands of identical notifications.

Each issue carries the full stack trace, a breadcrumb timeline of what led to the crash (HTTP requests, DB queries, log lines, user actions), the environment it occurred in, and the raw event payload.

Grouping and deduplication by fingerprint: SDK-provided, exception-based, or message hash
Breadcrumbs showing HTTP calls, DB queries, cache hits, and log lines before the crash
Full stack trace with source file, line number, and local variables
Source maps uploaded per release, resolved automatically on JS stack frames at render time
Assignments and comments: assign to a team member, leave notes directly on the issue
Status transitions: open, resolved, ignored, regressed
Search and filter by level, environment, project, release, time range, and free text
Regression detection when a resolved issue reappears in a new event
Real-time updates via SSE: new issues appear in the list without a page refresh
Data export up to 10,000 issues as JSON or CSV
Dark mode, first class. Every screen ships with a carefully designed dark theme. One click to toggle, persisted across sessions

Tindra issue detail with stacktrace and breadcrumbs

Transactions, span waterfalls, and where your time went.

Every traced request becomes a transaction with a full span waterfall: database queries, HTTP calls to external services, template renders, queue dispatches. See exactly where your 800ms went.

Transaction list with P50, P75, P95, P99 latency and throughput per endpoint
Span waterfall with DB, HTTP, template, task, and custom spans
Critical path highlighting: spans on the critical path are marked in amber, everything else dims so the bottleneck is obvious at a glance
Web Vitals for browser page loads (LCP, INP, CLS, FCP, TTFB) with P75 and pass rate per page
N+1 detection: repeated identical queries in a transaction are detected automatically and opened as issues
Error linkage from a transaction directly to the error that caused it
Custom spans via the standard Sentry tracing API in any SDK

Every deploy is a data point.

Tindra tracks releases automatically from the SDK's release tag. No manual setup. After a deploy, you can filter the issue list and transaction list to that release and immediately see what changed.

If something that was resolved in v1.4.2 reappears in v1.4.3, Tindra marks it regressed and surfaces it. Useful for catching the inevitable "fixed it in staging, broke it in prod."

Auto-created from SDK release tags: no API call needed to register a release
Per-release issue view showing every error that appeared in that deploy
Per-release transaction view with performance stats filtered to that release
Source map uploads scoped per release so the right map is applied to the right version
Regression linking connects a regressed issue back to the release where it reappeared

Releases

v1.4.3 2h ago

3 regressed 14 issues

v1.4.2 1d ago

- 1 issues

v1.4.1 3d ago

1 regressed 4 issues

v1.4.0 8d ago

5 regressed 22 issues

v1.3.9 14d ago

- 0 issues

v1.4.3 · issues

QueryTimeout: postgres exec exceeded 5s regressed

TypeError: Cannot read 'id' of undefined new

Get notified when something breaks. Not on every event.

Tindra sends alerts on conditions that matter: a new issue appearing for the first time, a resolved issue regressing, or an error rate crossing a threshold. Not a flood of identical notifications for each occurrence.

New issue alerts when a unique fingerprint appears for the first time
Regression alerts when a resolved or ignored issue comes back
Rate alerts when error count crosses a threshold in a rolling window
Email via any supported provider (SMTP, Postmark, Brevo, and more)
Slack and Discord: paste your incoming webhook URL and alerts post directly to any channel
Webhook with a structured JSON payload posted to any URL you control
Per-rule cooldown to avoid repeat notifications during an ongoing incident

Alert channels

Email

SMTP, Postmark, Brevo, Ahasend, Lettermint, Cloudflare

Slack

Incoming webhook URL, posts to any channel

Discord

Incoming webhook URL, posts to any channel

Webhook

JSON POST to any URL, full issue payload included

example webhook payload

{
  "rule_name": "High error rate",
  "trigger": "new_issue",
  "project_name": "my-app",
  "fired_at": "2024-11-15T14:32:00Z",
  "issues": [{ "title": "TypeError: …" }]
}

Change one line. Every Sentry SDK works out of the box.

Tindra implements the Sentry event ingest protocol. Any SDK that can send to Sentry can send to Tindra. Update the DSN in your config, deploy, done. No SDK changes, no adapter libraries, no rewriting instrumentation.

If you want a zero-risk migration, use the passthrough DSN: configure Tindra to forward every incoming event to a second endpoint while also processing it locally. Run both in parallel until you're confident, then cut the old one.

The DSN format is identical: point it at your Tindra instance
Official Sentry SDKs supported: PHP, Laravel, Go, Python, JavaScript, Rust, Ruby, Java, .NET, iOS, Android
Source maps, release tracking, and environment tagging all work as expected
Performance instrumentation (transactions and spans) supported where SDKs provide it
Passthrough DSN: forward events to a second Sentry-compatible endpoint simultaneously. Migrate with zero downtime and no data loss

# Before
SENTRY_DSN=https://key@sentry.io/123

# After: point at Tindra
SENTRY_DSN=https://key@acme.tindra.io/123

# Optional: keep forwarding to old endpoint during migration
PASSTHROUGH_DSN=https://key@sentry.io/123
            

Supported SDKs

PHP / Laravel

sentry/sentry-laravel

Go

getsentry/sentry-go

JavaScript

@sentry/browser · node

Python

sentry-sdk

Rust

sentry · sentry-anyhow

Ruby

sentry-ruby · sentry-rails

Java / Kotlin

sentry-java

.NET / C#

Sentry.Extensions.Logging

iOS / Android

sentry-cocoa · sentry-android

SSO, MFA, audit log, and fine-grained permissions.

Tindra ships with the access controls a real team needs. OIDC-based SSO works with any standards-compliant provider. TOTP MFA is built in. Roles keep people out of things they shouldn't touch.

SSO: native GitHub, Google, Microsoft, Auth0, Zitadel, and any OIDC-compliant provider. New users provisioned on first login
TOTP MFA: built-in two-factor authentication, no third-party service needed
Fine-grained permissions: separate controls for managing projects, issues, alerts, and users
API tokens: per-project bearer tokens for CI, integrations, and scripts
Audit log: structured log of every auth, user, project, token, alert, and issue action with actor IP and timestamp
Rate limiting: per-IP on login, per-project on event ingest
Session security: HttpOnly, Secure, SameSite=Strict cookies throughout

Audit log

auth.login.success alice@acme.io 2m ago

token.created bob@acme.io 14m ago

project.created alice@acme.io 1h ago

auth.login.fail 198.51.100.4 2h ago

user.invited alice@acme.io 3h ago

alert.created bob@acme.io 5h ago

Security settings

Two-factor authentication enabled

SSO provider google-workspace

API tokens 3 active

Sensitive data scrubbed before it hits the database.

PII scrubbing runs at ingest time. Data matching a rule never reaches storage. No scheduled cleanup job, no purge queue. If it matches, it never lands.

Field name scrubbing replaces any value whose key matches a pattern (password, token, api_key, credit_card, and more). Pattern scrubbing scans every string value with a regex. Both run on every event, recursively through nested objects.

Field name scrubbing: built-in list covers passwords, tokens, secrets, and card numbers
Pattern scrubbing: built-in patterns for email addresses and IP addresses
Custom field names: add your own application-specific fields
Custom regex patterns: match any sensitive value format
Applies everywhere: request bodies, query strings, breadcrumbs, user context, span data
Configurable per instance: admins manage rules from Settings, no redeploy needed

PII scrubbing rules

Field name rules

password → [Filtered]

api_key → [Filtered]

token → [Filtered]

secret → [Filtered]

credit_card → [Filtered]

ssn → [Filtered]

Pattern rules

email user@example.com built-in

ip IPv4 & IPv6 built-in

Scrubbing runs at ingest. No raw data is written to the database.

One binary and a Postgres. Or we run it for you.

The entire Tindra server is a single statically-compiled Go binary. Connect it to a Postgres database and you have the full stack. No sidecar processes, no object storage, no message broker.

One Docker image, one Postgres, a handful of env vars to configure
Upgrades: pull the new image and restart. No migration scripts to run
Retention: configurable per instance. Keep 30 days or 365, your call
License: Elastic License v3. Free to use, source available on GitHub

Managed instances are dedicated per customer: your own container, your own Postgres, hosted in the EU. Upgrades, backups, and the pager are on us.

Dedicated container and Postgres per customer, never shared
EU-only: all data stays in the EU, never replicated outside
Nightly encrypted backups with 14-day point-in-time recovery
Live in minutes, no infrastructure to provision

Self-hosted setup

$ bash -c "$(curl -sSL https://install.tindra.sh)"

Language	Go (single static binary)
Storage	Postgres 12+
RAM (minimum)	512 MB
Config	Environment variables
Upgrades	Pull new image, restart
License	Elastic License v3 (ELv3)

What Tindra does, and how it works.