Glossary

A short dictionary of Gotcha’s terms — from organizations and projects to profiles and quotas. Where a term has its own detail page, it’s linked.

Organization — the top level: groups projects, members (with roles), and shared settings (ingest limits, SSO, alert-channel templates). A user can belong to several organizations. Created together with the first project during /onboarding.

Project — a single application or service inside an organization. Each project has its own DSN keys, its own issues, transactions, metrics, profiles, and settings (sampling, regression thresholds, retention). Events from two different projects are never mixed.

Team — a group of organization members sharing access to a subset of projects. Used so you don’t have to grant organization-wide access to everyone who only needs a couple of projects.

Operator — a member on a team attached to a project (an org owner/admin qualifies too, automatically). An operator can run that project’s day-to-day monitoring — monitors, maintenance windows, status-page content, issue and metric alert rules, escalations, dependency-based storm suppression, SLOs, service recipes, host thresholds and groups, incident acknowledgment, exports (their own only) — without being promoted to organization admin. Alert channels, status-page publication, and project/organization settings stay owner/admin only; an operator who isn’t owner/admin sees alert-channel recipients masked. Full action table: Teams and roles.

DSN — a project’s connection string, shaped like https://<public_key>@<your-gotcha-host>/<project_id>, which you pass to the SDK at init time. It carries a public key (Gotcha resolves the project and organization from it) and the ingest address; unlike the older Sentry DSN format, there’s no secret component. You can find and reissue a DSN under “Project settings” or on the “Setup” page — see SDK & Integrations.

Event — a single occurrence: an error with a stack trace, level, tags, context, user data, and SDK info, sent to Gotcha over the Sentry ingestion protocol. Multiple events sharing a fingerprint collapse into one issue.

Issue — a group of identical events collapsed by fingerprint: one card instead of a stream of duplicates. An issue has a status (unresolved/resolved/ignored), an assignee, and an event count. More: Issues.

Grouping / fingerprint — the key events are grouped by into an issue, computed from the error type, message, and code location (call stack). A new event with an already-seen fingerprint bumps the existing issue’s counter; a new fingerprint opens a new issue (or reopens a resolved one — that’s what a regression is).

Transaction — a unit of performance: one handled request or operation as a whole, with an overall duration and status. Sent by the SDK when tracing is enabled (traces_sample_rate/tracesSampleRate > 0). More: Performance.

Trace — an end-to-end chain of related transactions and spans for a single request, including across service boundaries (when trace_id is propagated between them). From an issue’s detail page you can jump to the related trace if the error happened inside a traced request.

Span — a nested segment inside a transaction: a database query, an HTTP call to another service, a template render, and so on. A transaction is essentially a root span plus a tree of children.

Web Vitals — page-speed metrics measured in a real user’s browser: LCP, INP, CLS, FCP, TTFB. Shown with a p75 percentile and a good/needs-improvement/poor rating. Collected automatically by the browser SDK when tracing is enabled. More: the Web Vitals tab under Performance.

Metric — a numeric time series (counter/gauge/histogram) with arbitrary labels (environment, release, region, etc.), sent over the OTLP protocol. Viewable as p50/p95/avg/sum aggregations over a period. More: Metrics.

Profile / flame graph — a snapshot of where CPU time or execution time goes inside your application during a real request, captured by the SDK (Sentry profiling) or uploaded directly in pprof format. A flame graph visualizes a profile as a call stack: a block’s width is its share of time, and nesting is call depth. More: Profiling.

Uptime monitor — a periodic availability check (HTTP/TCP/DNS/heartbeat) run on a schedule. Several consecutive failed checks open an incident. More: Uptime.

Incident — a period during which a monitor or a regression signal is considered “down”: it has a start, an optional end, and a history of checks/events within it. An incident can trigger an alert and update a public status page.

Incident group — incidents from several sources (hosts, uptime, host-labeled metric thresholds, uptime-type SLOs) whose nodes are chained through downed dependencies to one root incident. While the root is open and informing, group members hold back their own notifications — the on-call engineer sees one message instead of a storm. More: Incident groups.

Root incident — an availability incident of a node (a silent host or a down uptime monitor) that an incident group is built around; threshold incidents of a host (disk/memory/load) never become roots. More: Incident groups.

Alert channel — a delivery method for notifications: email, webhook, or a Telegram bot. Configured once per project and reused across multiple rules.

Alert rule — a condition to react to: a new issue, a regression (an issue reopening), a spike in errors over a time window, or a metric crossing a threshold. There’s no separate step to “attach a channel to a rule” — an enabled rule notifies every enabled channel of the project at once; a given rule’s firings are throttled so the team isn’t flooded with duplicates. More: Alerts.

Regression — a statistically significant degradation of a metric (endpoint latency, Web Vitals, time spent in a profile) relative to a baseline from a prior period, detected automatically. Performance regressions show up as issues under Performance.

Retention — how long a given kind of data (events/transactions, trace spans, metrics, profiles) is kept in ClickHouse before it’s deleted. Set instance-wide by GOTCHA_EVENT_RETENTION_DAYS and friends; there is no per-project override — the “Data retention” card in project settings shows the instance value, it does not change it.

Quota — a monthly cap on ingesting a given kind of data (events, transactions, metrics, profiles) per organization. It is counted per item, not per HTTP request: an envelope carrying a thousand events spends a thousand units. If less room is left than the batch needs, the remainder is accepted and the excess is dropped and counted as rejected. Once exhausted, new items of that kind are rejected (ingest responds 429) until the next month starts; already-ingested data is not deleted. Configured under “Organization settings → Usage & rate limits”; 0 means unlimited.

Environment — an arbitrary string (production, staging, dev, …) the SDK attaches to every event, transaction, and metric. Used for filtering across nearly every section, so production errors don’t drown among local-dev noise.

Release — a version identifier for your application (e.g. a git hash or a build number) that the SDK attaches to events and transactions. Lets you see which release an issue first appeared in, or in which release a performance regression started.