Skip to main content
Before you dive into the SDK reference or platform guides, it helps to understand the vocabulary Argus uses throughout its dashboard, API, and documentation. This page explains each key term and shows how the pieces connect — from the moment your SDK captures an error to the alert that lands in your inbox.
A DSN is a connection string that uniquely identifies your Argus project. You paste it into init() once; every SDK call after that uses it automatically.Format:
Argus parses the DSN into four parts at startup:
PartWhere in the URLPurpose
protocolhttps (or http)Determines whether the request is encrypted
publicKeyThe username before @Authenticates your SDK with the ingest API
hostHostname and optional portRoutes the request to the right Argus server
projectIdThe path segment after /Scopes the event to your project
A malformed DSN (missing public key, missing project ID, or an invalid URL) throws an error immediately at init() — loudly, so you catch misconfiguration at startup rather than silently dropping events in production.You can find your DSN at any time under Project Settings → DSN.
An envelope is the JSON payload that the SDK builds and sends to the Argus ingest endpoint every time an error is captured.Envelope fields:
FieldTypeDescription
levelfatal | error | warning | info | debugSeverity of the event
timestampnumber (milliseconds)Date.now() at capture time — must be ms, not seconds
environmentstringe.g. "production", "staging" — set in init()
releasestringYour app version — ties errors to a specific deploy
exceptionobject{ type, value, stacktrace: { frames[] } }
userobjectOptional { id, email } for user-scoped error views
breadcrumbsarrayOrdered trail of events leading up to the error
tagsobjectArbitrary key–value strings for filtering
requestobject{ url, method, headers } — auto-populated in the browser SDK
Invalid envelopes return HTTP 400 with details. The timestamp field is strictly enforced in milliseconds — a Unix seconds value is rejected.
An event is one captured occurrence of an error in your application. Every time the SDK sends an envelope and Argus accepts it, Argus creates an event record containing:
  • The full stack trace with filenames, function names, line numbers, and column numbers
  • Context such as the browser or OS, the URL where the crash happened, and any tags you attached
  • Metadata including the severity level, timestamp, environment, and release
Events are the raw material Argus works with. On their own they’re detailed records of individual crashes; grouped together they become Issues (see below).You can browse all events for a specific issue on the Issue Detail page in the dashboard, filtered and paginated by time.
Argus automatically groups identical errors into the same issue using a fingerprint — a hash derived from the top stack frames of an exception. This means:
  • The same bug triggered by different users maps to the same issue
  • The same bug occurring across multiple deploys maps to the same issue (until the relevant code locations change)
  • Different bugs with the same error message but different stack traces map to different issues
The same error thrown in Chrome and Firefox also produces the same fingerprint — Argus normalises both stack formats to a common structure before computing the hash.
Minified production builds can cause multiple distinct bugs to collapse into a single fingerprint if minification maps many source lines to the same output line. Source map resolution (planned) will address this.
Every issue moves through a simple lifecycle controlled by you:
StatusMeaning
UNRESOLVEDThe issue is active. New matching events increment its count.
RESOLVEDYou’ve fixed the bug. Argus stops alerting on this fingerprint.
IGNOREDYou’ve acknowledged the issue but don’t plan to fix it. Alerts silence.
Change an issue’s status from the Issue Detail page using the Resolve or Ignore buttons, or via the REST API (PATCH /api/v1/issues/:id).
If a resolved issue reappears after a deploy — meaning a new event with the same fingerprint arrives — Argus automatically moves it back to UNRESOLVED and fires your alert rules again.
An alert rule defines the condition that triggers a notification and where that notification goes.Current rule type:
TypeWhen it fires
NEW_ISSUEThe first time a new fingerprint is seen — i.e., a bug Argus has never grouped before
Delivery channels:
  • Email — Argus sends a formatted notification to the address you configure on the rule
  • Webhook — Argus POSTs a JSON payload to any HTTPS URL you provide, so you can pipe alerts into Slack, PagerDuty, or your own tooling
Each rule is scoped to a single project. You can create, enable, disable, and delete rules from the Alerts page in the dashboard. Every delivery attempt is logged — check Alert Logs if a notification doesn’t arrive as expected.
Argus enforces a monthly event quota per organization, reset at the start of each billing period.
PlanMonthly limit
Free10,000 events
Pro500,000 events
When your organization hits its cap:
  • The ingest endpoint returns HTTP 429
  • The SDK detects the 429 response and drops the event silently — no retry, no exception thrown in your app
  • Your application continues running normally
Monitor your current usage on the Usage page in the dashboard. When you’re approaching your limit, Argus prompts you to upgrade.
Events dropped due to quota are gone permanently. If error visibility during high-traffic periods matters to your team, upgrade to Pro before you hit the cap rather than after.

​
Explore the Platform

Issues

Browse, filter, and triage the issues Argus has grouped from your events.

Alerts

Configure email and webhook rules so the right people hear about new bugs instantly.

Performance

Track transaction durations and web vitals across your application.

Usage & Billing

Monitor your monthly event consumption and manage your plan.