Install an SDK

Install an Errorgap SDK in each application or service you want to monitor. The SDK captures unhandled exceptions, attaches runtime context, and sends events to the project you created in Errorgap.

Choose your runtime

Start with the runtime that owns the failure path your team wants to monitor first. For a web product, that may be the browser application, the API service, or the background worker that processes customer jobs.

• Install one SDK per application runtime.
• Use the same project key for one application across its environments.
• Create separate projects when services have different owners or triage queues.

Find your project key

The project key tells the SDK which Errorgap project should receive events. You can find it in the project settings for the project you want to connect.

1. Open the project in Errorgap.
2. Go to project settings.
3. Copy the project key from the setup or general settings area.
4. Store the key with your application configuration for each environment.

Initialize the SDK

Initialize the SDK as early as practical in your application startup so it can capture errors during boot and request handling. The exact package name and import style depend on your runtime.

// Example shape only. Use the SDK package for your runtime.
import { Errorgap } from "@errorgap/sdk";

Errorgap.init({
  projectKey: "egp_your_project_key",
  environment: "staging",
  release: "2026.06.10"
});

Keep the project key out of source files when your application already has a configuration system. For browser applications, use the public client-side setup recommended by the SDK guide for that runtime.

Set environment and release

Environment and release values make Errorgap more useful during triage. They let your team filter noise, compare behavior across deploys, and understand whether an issue is limited to a non-production target.

• Environment should be a stable value such as production,staging, or development.
• Release should identify the running version, deploy, or commit that produced the event.
• Service name, when supported by the SDK, should match the project or application name your team recognizes.

Keep sensitive data out of telemetry

Errorgap is built for operational telemetry — errors, logs, traces, and deploy metadata. Do not send secrets or regulated data in the events your application transmits. You are responsible for the data you choose to send, and you remain its controller.

• Never send passwords, API keys, access tokens, session cookies, or Authorization headers in error context, request bodies, or breadcrumbs.
• Do not send regulated data — payment card numbers, health information (PHI), or government IDs. These are out of scope and not supported without a separate written agreement.
• Scrub values at the source where you can, and configure redaction rules so matched values are removed before they are stored.
• Be deliberate about attaching request bodies, query parameters, and custom context — they are the most common place secrets leak into telemetry.

See the redaction rules guide and the public Acceptable Use Policy for what may not be sent.

Verify the installation

After the SDK is initialized, send one test error from a non-production environment and confirm it appears in the Errorgap project. A successful first event should include the error message, stack trace, environment, release, and the time it occurred.

If the error does not appear, check that the application is using the expected project key, the SDK initialization runs before the test error, and the environment value matches the filters you are viewing in Errorgap.

Next steps

Once the SDK is installed, send a deliberate test error and use the resulting error group to confirm that the stack trace, context, and project routing look right for your team.

After verification, tune event throttling and API key settings, add redaction rules, decide whether to enable session replay, and create scoped agent tokens only for agents that need project evidence.