The whole product, screen by screen.

Follow an error into the logs, the request and the code that explain it. Then watch your endpoints and cron jobs so the next one doesn’t happen quietly. One Go binary and Postgres, on your box or on a dedicated instance we run in the EU.

Errors, grouped. With the trail that led there.

Captured errors are grouped by fingerprint so your team can work through recurring problems together. Open an occurrence to inspect the context your SDK supplied.

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 stored event payload.

PaymentGatewayTimeout in Tindra, regressed in 3.8.0, with its event chart and stack trace

Errors group by fingerprint: the SDK’s, the exception’s, or a hash of the message.
Stack traces carry the source file, line number and local variables.
Breadcrumbs show the HTTP calls, queries, cache hits and log lines before the crash.
Source maps upload per release and resolve on your JS frames when you open them.
A resolved issue that shows up again gets marked regressed.

Full list (9 more)

Assignments and comments: assign to a team member, leave notes on the issue
Status transitions: open, resolved, ignored, regressed
Bulk operations: resolve, ignore, assign or re-open many issues at once
Merge and unmerge: combine related issues, split them back if needed
Search and filter by title, status, level, tags, and the shared project, environment, user and time
Refresh controls: pause automatic updates while you investigate, refresh to get back to the latest
Data export of up to 10,000 issues as JSON or CSV
Dark mode: every screen has a dark theme. One click to toggle, remembered across sessions
Works on a phone: triage an error at 2am without pinching to zoom

Start with a customer’s error and follow what happened.

Someone reports a failed checkout. Select their identity on the error event, narrow the time range, and carry that context into logs and performance. You can follow their captured activity without rebuilding each search.

One investigation context: project, environment, user, and time follow you between telemetry views
Individual activity: selecting a user shows their traces and browser page loads
Shareable links: send a rolling window or fixed interval to a teammate with access

Follow a user across signals or read how shared filters work.

Move from the symptom to the work behind it.

Inspect the error Read the stack, breadcrumbs, release and affected user.
Find the log Search the message and inspect the structured attributes around the failure.
Open the trace Follow a matching stored transaction into its database calls and other spans.
Check the browser Inspect the user’s captured page loads and available Web Vitals.

Use the same SDK user ID across related apps. Tindra can only follow what your SDKs send and sample, so that ID is what ties the trail together.

Jane Doe’s issues with shared project and time filters

Read the logs around the failure, then follow the trace.

Search structured log messages within your investigation, expand a row for its attributes, and open a matching stored transaction when trace context is available.

Focused searches: combine message text and severity with project, environment, user, and time
Structured context: inspect the full attributes, release, trace ID, and span ID
Volume alerts: prefill a rule from projects, environment, level, and message search

Alerts evaluate their own rolling window and minimum severity. Your selected user and fixed investigation interval stay with the investigation.

Read the log viewer guide and configure an alert.

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.

Span waterfalls with database, HTTP, template, task and custom spans.
The critical path turns amber and everything else dims, so the bottleneck stands out.
The same query repeated in one request (an N+1) opens an issue by itself.
Web Vitals for browser page loads: LCP, INP, CLS, FCP and TTFB, with P75 and pass rate per page.
A flame graph under the waterfall when the transaction carried a profile. More below.

Full list (5 more)

Endpoint metrics for latency and throughput, switching to individual traces when you select a user
Queries, caches and jobs scoped to the selected user through their transactions
Apdex score per endpoint and as a weighted average on the dashboard (T=500ms, coloured green, yellow or red)
Error linkage from a transaction straight to the error that caused it
Custom spans through the standard Sentry tracing API in any SDK

Spans stop where your tracing stops. Profiles don’t.

Spans only show you what you instrumented. When a span is slow for no obvious reason, the answer is usually in code nobody wrapped in a tracer. Turn on your SDK's profiler and Tindra folds the samples into a flame graph, rendered right under the waterfall on the same page.

Sampled PHP call stacks in the transaction flame graph — A sampled PHP transaction, down to its database, cache, and template calls.

Profiling works with supported PHP / Laravel, Python, Node.js, browser, and Ruby SDKs. Check the profiler and setup requirements for your SDK.

Self time and total time per frame, so you can tell a slow function from a slow call path.
Click a frame to zoom in. The breadcrumb or Esc walks you back out.
Profiles never count against your monthly event quota.
One checkbox per project stops accepting profiles from a noisy service. No SDK redeploy.

Full list (6 more)

Both wire formats: transaction-based profiles and continuous profiling chunks. Tindra slices the right window out of a continuous session automatically
Search frames to dim everything that does not match, keeping hits in the context of their stack
Honest milliseconds: the sample interval is measured from the samples themselves, not assumed from the SDK's nominal rate
App and library frames colored differently, idle samples reported separately instead of faked into the tree
Folded server side: the browser gets a tree of a few hundred nodes, not megabytes of raw samples
Frame metadata scrubbed through your project's PII patterns before it is stored. Absolute paths included

Profiles are much bigger than events, so they get their own short retention window and an instance-wide storage budget instead of following your event retention. Set it once and forget it: oldest profiles roll off, nothing else is touched.

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

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.

Log alert configuration and delivery history — A log alert’s scope, threshold, and recorded delivery result. This demo rule is paused.

New issue alerts the first time a fingerprint shows up.
Regression alerts when a resolved or ignored issue comes back.
Rate alerts when the error count crosses a threshold in a rolling window.
Log volume alerts, including Alert on this straight from the log viewer.
Delivery to email, Slack, Discord, Microsoft Teams or a webhook.

Full list (9 more)

Global rules for issues and monitors, with project selection when you need a narrower scope
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 your configured HTTP(S) endpoint
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

Also in the binary.

No add-ons, no separate services. Every instance ships with all of this.

Dashboard

The first screen you see. Every project feeds one live view: latency, throughput and Apdex, a 7-day traffic heatmap, the five hottest issues and the five slowest endpoints.

See the dashboard See the dashboard

Full list (4 more)

Shared filters: focus transaction metrics by project, environment, user and time
Recent releases: the latest deployments
Alert activity: the last rules to fire, so you can see what has been noisy
Current state: issues, alerts, releases and monitors keep their own scope, and the heatmap always shows seven days

Releases

Releases come from your SDK’s release tag. No setup, no API call. Filter issues and transactions to one deploy, and anything resolved in v1.4.2 that shows up in v1.4.3 gets marked regressed.

See a release See a release

Full list (5 more)

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

Setup and SDKs

Keep your Sentry SDK and point it at your project’s Tindra DSN. The setup page tells you when a tagged test event is actually stored, then checks transactions, profiles and source maps on their own.

See the setup check See the setup check Connect and verify your app

Full list (14 more)

Guided connection checks with a project DSN, tagged test, and storage confirmation
Source-map verification showing the release, matching bundle URL, and resolved original location. Upload and verify source maps
Optional tracing and profiling where supported by your SDK
Passthrough DSN for best-effort comparison with another service during migration
Missing data: guidance when optional transactions or profiles have not arrived

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

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

# After: point at Tindra
SENTRY_DSN=https://your-key@acme.tindra.sh/your-project-id

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

MCP server

A built-in MCP server on POST /mcp. Ask Claude, Cursor or Windsurf about open issues, slow endpoints, cron health and recent logs from the tool you’re already in. Tokens are per project and read-only unless you enable writes.

Read the MCP docs

Full list (6 more)

Complete event context: inspect stack frames, breadcrumbs, request data, and older occurrences before deciding what to change
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, and every query returns that project’s data
Works with any MCP client: Claude Desktop, Cursor, Windsurf and anything that supports Streamable HTTP
Built in, no config needed: the MCP server is part of the Tindra binary and on every instance

A selection of MCP tools
MCP tools	What it does	Access
`get_overview`	health summary across all monitors & alerts	read
`list_issues`	issues filtered by status, level, or search	read
`get_issue`	event payload, breadcrumbs, and older occurrences	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 with Claude Code

$ claude mcp add --transport http tindra \
    https://acme.tindra.sh/mcp \
    --header "Authorization: Bearer tindra_…"

Security and access

Single sign-on with GitHub, Google, Microsoft, Auth0, Zitadel or any OIDC provider (managed: Studio and Scale). TOTP MFA is on by default, permissions are split by area, and an audit log records who did what.

See users and permissions See users and permissions

Full list (7 more)

SSO: Native GitHub, Google, Microsoft, Auth0, Zitadel, and any OIDC-compliant provider. New users join by invitation with a verified provider email; administrators can explicitly link existing accounts when needed
TOTP MFA enforced by default: Users enroll a local authenticator before accessing the app and verify it after password or SSO login. No third-party service needed. Enrollment can be made optional
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 for supported project mutations via the MCP server or API; instance administration still requires user permissions
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 session cookies, secure cookies for HTTPS deployments, and revocation of old sessions when passwords change

Privacy and PII

Field-path and pattern rules per project scrub errors, transactions, logs and profiles before they’re stored. Keep the context you need, drop what you don’t want to hold.

See the privacy settings See the privacy settings Read the privacy coverage

Full list (5 more)

Exact field paths for request headers, structured data, and user identity fields
Built-in patterns for email and IPv4 addresses, enabled per project
Signal-specific coverage including log bodies and attributes, span data, and profile frame metadata
Explicit configuration through each project’s Data privacy settings
New ingestion only: rules apply to new data. Forwarded passthrough content and source text added during enrichment behave separately

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.

Self-hosted

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

One Docker image, one Postgres, a handful of env vars to configure
Upgrades: automatic startup migrations and graceful draining, with a documented backup and upgrade workflow
Retention: configurable telemetry retention, with separate profile budgets and row caps
Health overview: storage, recent data volumes, retention, and usage gauges in Settings
Ingestion monitoring: authenticated Prometheus metrics for pending data, write failures, and recovery
License: Elastic License 2.0. Free to use, source available on GitHub

Self-host Tindra and monitor ingestion health.

View storage and retention overview View storage and retention overview

Managed in the EU

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

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

Try it. Self-hosted or managed.

Pull the Docker image and you are running in minutes. Or start a managed trial and have your own instance ready before your coffee is done.

Start free trial Read the docs