> ## Documentation Index > Fetch the complete documentation index at: https://docs.arguserror.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Argus FAQ: Plans, SDK Retries, Error Grouping, and Alerting > Common Argus questions answered: plans and event limits, SDK retry behavior, error deduplication, supported platforms, and alert webhooks. Here are quick, direct answers to the questions developers ask most often about Argus — covering plans and limits, SDK internals, error grouping, and alerting. If your question isn't here, check the [Troubleshooting guide](/troubleshooting) or open a discussion on the Argus repository. No. The DSN public key is safe to include in client-side JavaScript bundles, environment variables checked into version control, or any other place your application config lives. The key is a **write-only ingest credential** — it grants permission to send events to one specific project and nothing else. It cannot be used to read issues, access account data, or make any change to your Argus configuration. Only your session credentials (email/password or OAuth) can do those things. If you accidentally rotate a DSN, update the `dsn` option in your `init()` call and redeploy. The old key stops working immediately. Once your organization reaches its monthly event limit, the ingest endpoint returns **HTTP 429** for every subsequent event that month. The Argus SDK handles 429 responses by **dropping the event silently** — it never throws an error or interrupts your application in any way. Your users won't notice anything, but those events won't appear in your dashboard. Your quota resets automatically at the start of each calendar month (tracked as `YYYY-MM`). To avoid gaps in coverage, monitor your usage on the **Usage** page in the dashboard and upgrade to Pro before you hit the limit. | Plan | Monthly limit | Price | | ---- | -------------- | ------- | | Free | 10,000 events | \$0 | | Pro | 500,000 events | \$10/mo | When the same error occurs multiple times, Argus groups those occurrences together into a single Issue rather than creating a new Issue card for every individual event. You see one Issue with a rising event count, not thousands of duplicate cards. **Practical implications:** * The same bug triggering 10,000 times appears as one Issue with a count of 10,000, not 10,000 separate Issues. * If you fix a bug and deploy a new release, the updated stack frames produce a different fingerprint and a new Issue — old and new occurrences are kept separate. * Minified code without source maps can cause unrelated errors to share a fingerprint (minified line numbers collapse multiple call sites onto the same line). Source map resolution, which will restore original filenames and line numbers, is on the roadmap. **How the grouping key is computed** Argus generates a SHA-256 fingerprint from the top 5 stack frames of the exception — each frame contributes its filename, function name, and line number. Two events with the same fingerprint are counted as the same Issue; a different fingerprint creates a new one. It depends on your plan: * **Free plan** — 1 project per organization. Creating a second project is blocked until you upgrade. * **Pro plan** — unlimited projects per organization. Each project gets its own unique DSN, its own issue list, and its own alert rules. Use separate projects for logically separate applications (for example, your marketing site and your API backend) so their issues don't mix. To upgrade, go to **Settings → Billing** in the dashboard. Argus currently ships SDKs for: | Platform | Package | Notes | | -------------------------- | ----------------------- | -------------------------------------------------------------------------------------- | | Browser (any JS framework) | `@argusdev/sdk-browser` | Hooks `window.onerror` and `unhandledrejection`. | | Node.js | `@argusdev/sdk-node` | Hooks `uncaughtException` and `unhandledRejection`; includes Express middleware. | | React | `@argusdev/sdk-react` | Adds `` on top of `@argusdev/sdk-browser` for render-phase errors. | **On the roadmap:** React Native, Vue, Go, and additional platforms. All three current SDKs have zero runtime dependencies. The transport layer retries failed requests up to **2 times** with exponential backoff before giving up: | Attempt | Delay before retry | | --------- | ------------------ | | 1st retry | 1 second | | 2nd retry | 2 seconds | Retry behavior varies by response type: * **5xx or network error** — retries up to 2 times, then logs `[argus] failed to send event after retries` to the console. * **429 (quota / rate limit)** — drops immediately with no retry. Retrying a rate-limited endpoint would only make congestion worse. * **4xx other than 429** — warns once with `[argus] event rejected by server (4xx)` and does not retry. The payload or key is wrong; retrying won't fix it. * **2xx** — returns immediately; no retry needed. In all failure cases the SDK logs a `console.warn` and moves on — it never throws an error into your application. Under normal conditions the overhead is negligible: * **Zero runtime dependencies** — all three SDKs (`sdk-browser`, `sdk-node`, `sdk-react`) ship with no third-party dependencies, keeping bundle size minimal. * **Global hooks only** — the SDK instruments `window.onerror`, `unhandledrejection`, `uncaughtException`, and `unhandledRejection`. It doesn't patch any standard library methods or intercept normal function calls. * **Fire-and-forget transport** — `captureException()` is async. The ingest POST runs in the background and does not block your request/response cycle. Error events are rare by definition, so even the cost of the network POST has no impact on your application's steady-state performance. Yes — use a **webhook alert rule**. When a new issue matches the rule's conditions, Argus sends an HTTP POST with a JSON body to any URL you specify. To set one up: 1. Open **Alerts** in the dashboard for your project. 2. Click **New Alert Rule** and select **Webhook** as the delivery channel. 3. Paste your destination URL: * **Slack:** use a [Slack Incoming Webhook URL](https://api.slack.com/messaging/webhooks). * **PagerDuty:** use your [PagerDuty Events API v2](https://developer.pagerduty.com/docs/events-api-v2/overview/) integration URL. * **Any HTTP endpoint:** any URL that accepts a POST request with a JSON body works. 4. Save the rule — Argus fires it the next time a matching new issue is created. More native integrations (dedicated Slack and PagerDuty apps with richer formatting) are planned for a future release. You have two options: **From the dashboard** Open the issue and click **Resolve**. The status changes to `RESOLVED` immediately. **Via the API** Send a `PATCH` request to the issue endpoint: ```http theme={null} PATCH /api/v1/projects/:projectId/issues/:issueId Content-Type: application/json { "status": "RESOLVED" } ``` **Automatic re-opening** If the same error fires again after you resolve it — for example, the fix introduced a regression — Argus automatically sets the status back to `UNRESOLVED` and re-triggers any alert rules. You don't need to manually re-open it. Each event envelope contains: | Field | Description | | ----------------------------- | -------------------------------------------------------------------------------------- | | `exception.type` | The error class name (e.g. `TypeError`). | | `exception.value` | The error message string. | | `exception.stacktrace.frames` | Full stack trace — filename, function name, line number, and column number per frame. | | `timestamp` | Milliseconds since epoch (`Date.now()`). | | `environment` | The value you pass to `init()` (e.g. `"production"`). | | `release` | The value you pass to `init()` (e.g. a git SHA or version string). | | `request.url` | The current page URL (browser) or left empty for Node.js unless you set it explicitly. | | `request.method` | HTTP method, if provided. | | `user` | Optional `id` and `email` if you pass user context to `captureException()`. | | `tags` | Optional key/value string pairs for custom categorization. | | `contexts.browser` | Browser name and version (browser SDK only). | | `contexts.os` | OS name and version (browser SDK only). | | `breadcrumbs` | Optional ordered list of events leading up to the error (up to 100). | | `level` | Severity level: `fatal`, `error`, `warning`, `info`, or `debug` (defaults to `error`). | Argus does **not** capture request headers, cookies, or body content unless you explicitly include them in the `request` field when calling `captureException()`.