Send a test error

A test error confirms that your SDK is installed, your project key is correct, and your team can find the resulting error group in Errorgap. Send the test from a non-production environment before relying on the setup for real incidents.

Why send a test error?

A successful test event proves the full path from application code to Errorgap is working. It also gives your team a low-risk error group to inspect before production failures arrive.

• Confirm that events are routed to the expected project.
• Verify that environment and release values appear correctly.
• Check that stack traces and runtime context are useful for triage.
• Make sure team members know where to find the error group.

Trigger a safe error

Add a temporary test path, command, or local action that raises a recognizable exception. Keep it isolated from customer traffic and remove it after you confirm the event appears.

// Example shape only. Use the pattern recommended by your SDK.
function sendErrorgapTestError() {
  throw new Error("Errorgap test error - safe to ignore");
}

sendErrorgapTestError();

Use a clear message such as Errorgap test error - safe to ignore so the event is easy to search for and does not look like a real customer-impacting failure.

Find the error group

1. Open the project connected to your SDK project key.
2. Go to the project error list.
3. Filter to the environment where you triggered the test error.
4. Search for the test error message.
5. Open the matching error group.

If the error group does not appear immediately, wait briefly and refresh the error list. Some SDKs send events asynchronously, especially during local or staging tests.

Inspect the details

Open the test error group and confirm the details match the application run that generated the event.

• Message matches the deliberate test error.
• Environment is the expected non-production target.
• Release identifies the current deploy, version, or commit when provided.
• Stack trace points to the test location in your application code.
• Context includes useful runtime or request details without exposing sensitive data.

Troubleshooting

If the test error does not appear, start with the configuration values visible to end users. Most first-run issues come from a mismatched project key, an unexpected environment filter, or SDK initialization running after the test error is thrown.

• Confirm the SDK is using the project key from the project you are viewing.
• Confirm the error was triggered after SDK initialization completed.
• Clear or adjust environment and status filters in the error list.
• Check whether the test happened in a runtime or worker that has the SDK installed.
• Trigger the test again with a unique message and search for that exact text.

Next steps

After the test error appears, remove the temporary trigger and invite the teammates who will triage errors for this project. You can then configure integrations and notification paths so real failures reach the right people.

Before production rollout, also review project settings, redaction, agent access, and session replay so future evidence is useful and appropriately scoped.