How Tindra Works - Error Tracking and Performance Monitoring

Everything important, one screen.

The dashboard is the first thing you see when you open Tindra. It aggregates signal from every project into a single live view so you know the health of your entire stack at a glance.

KPI strip: open issue count, 24h error rate, P95 latency, Apdex score, and event throughput, live and auto-refreshing
Traffic heatmap: 7-day × 24-hour grid showing when your application is busiest
Hot issues: top 5 most frequently occurring errors right now
Slow transactions: top 5 endpoints by P95 latency
Recent releases: latest deployments at a glance
Alert activity: last rules to fire, so you can see what has been noisy
Multi-project: aggregated across all selected projects, not per-project silos

Dashboard

Open Issues

14

Error Rate

1.2%

P95 Latency

320ms

Apdex

0.91

Events / 24h

48,291

Hot issues

TypeError: Cannot read properties of null 1,842

Error: connect ETIMEDOUT 10.0.0.5:5432 631

RuntimeException: Queue worker timeout 204

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
Bulk operations: resolve, ignore, assign, or re-open multiple issues at once
Merge and unmerge: combine related issues into one, split them back if needed
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
Fully responsive: every screen works on mobile. Triage an error at 2am without pinching to zoom

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
Apdex score: satisfaction-weighted performance score per endpoint and as a weighted average on the dashboard (T=500ms, color-coded green/yellow/red)
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

Know when jobs miss and services go down.

Tindra monitors two things: scheduled jobs that should run on a cron schedule, and HTTP/HTTPS endpoints that should always be up. Both feed into the same alert rules and notification channels.

Cron monitors

Cron expression schedules with human-readable summaries and next expected run time
Configurable grace period before a late job is marked as missed
Multiple protocols: simple GET/POST ping URL, Sentry Crons SDK, or Spatie Laravel Schedule Monitor
Check-in history showing the last 20 runs with status, duration, and environment
Pause during deployments to suppress missed alerts during planned maintenance

Uptime monitors

HTTP and HTTPS probes every 30 seconds, up to 20 concurrent
Configurable timeout, interval, and expected status codes (ranges and lists supported)
Body content check to confirm a string is present in the response
State machine: goes down after 2 consecutive failures, recovers on the first success
Uptime checks excluded from your monthly event quota

Monitors

daily-backup

Every day at 03:00

ok

4m ago

email-queue-drain

Every 5 minutes

ok

2m ago

nightly-report

Every day at 02:00

missed

14h ago

db-cleanup

Every Sunday at 01:00

ok

2d ago

nightly-report · last 8 runs

Get notified when something breaks. Not on every event.

Tindra sends alerts on conditions that matter: a new issue, a regression, an error rate spike, or a cron job that stopped running. Not a flood of identical notifications for each occurrence.

Global rules that watch every project at once, or scoped to one or more specific projects
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, Discord, and Microsoft Teams: paste your incoming webhook URL and alerts post directly to any channel
Webhook with a structured JSON payload posted to any URL you control
Cron missed and cron error conditions for scheduled job alerts
Uptime down and uptime recovered conditions for HTTP monitor alerts
Per-rule cooldown to avoid repeat notifications during an ongoing incident
Delivery history: every alert firing is logged with status, trigger, and item count
Automatic webhook retry: failed deliveries retry at 2 minutes and 10 minutes before giving up

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

Microsoft Teams

Incoming webhook URL, Adaptive Card posted 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 enforced by default: users must set up two-factor authentication before accessing the app. No third-party service needed. Disable with REQUIRE_MFA=false
Fine-grained permissions: separate controls for managing projects, issues, alerts, and users
API tokens: per-project bearer tokens, read-only by default. Enable write access at token creation to allow mutations via the MCP server or API
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

Query your entire stack from any AI assistant.

Tindra ships a built-in MCP server on POST /mcp. Connect Claude, Cursor, Windsurf, or any MCP-compatible tool and ask about open issues, slow endpoints, cron health, and recent logs without leaving the tool you're already in.

Authenticate with a per-project API token. Write access is opt-in: read-only tokens work everywhere, writable tokens unlock mutations.

12 read tools: overview summary, issues, transactions, span data, monitors, releases, alert rules, logs, transaction waterfalls, and issue events
3 write tools: update issue status or assignee, bulk update issues, create alert rules
Project-scoped: each token is tied to one project. All queries return data for that project automatically
Read-only by default: tokens cannot mutate anything unless write access is explicitly enabled at creation
Works with any MCP client: Claude Desktop, Cursor, Windsurf, and any tool that supports Streamable HTTP
Built in, no config needed: the MCP server is part of the Tindra binary and available on every instance

Read the MCP docs

MCP tools

get_overview health summary across all monitors & alerts read

list_issues issues filtered by status, level, or search read

get_issue full detail with top stack frames read

list_transactions endpoints sorted by P95 latency read

list_monitors cron monitors with current state read

get_logs structured log search with trace filter read

update_issue resolve, ignore, or reassign an issue write

bulk_update_issues apply status change to multiple issues write

create_alert_rule create a new alert with channel & condition write

connecting to Claude Desktop

{
  "tindra": {
    "command": "npx",
    "args": ["mcp-remote", "https://acme.tindra.sh/mcp"]
  }
}

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
Health overview: DB size, ingestion rates, retention status, and quota gauges in Settings
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.