Activation guide

It should only take about a minute for your first events to be processed and appear in the UI as your account is provisioned. (After that, events typically only take seconds from being created to become visible in the Raygun app.)

Your first Crash Reporting or Real User Monitoring event is often the hardest to successfully send into Raygun. If you're having trouble, see if you're affected by one of the common setup issues below.

Examples shown in this doc use JS or .NET. However, if you're using another language or framework, please see our docs for more language specific examples

For APM, please see this APM troubleshooting guide

  1. Add a Raygun provider
  2. Add API key and other config settings
  3. Trigger an event
  4. Check there's a clear pipe from your app to the Raygun server

Please see our setup guides for your specific language or framework

We have 2 common ways of setting up Raygun in JS applications.

  1. Adding a code snippet in the head of the page, which will load the provider from a CDN hosted by us.
  2. Adding an NPM package.

If you use the code snippet method, and have ensured your API key & other settings are correct, you can typically expect events to be sent shortly after you load the page (or maybe have an error thrown!) Then, you can typically expect events to be sent shortly after you load the page (or maybe have an error thrown!)

If you use NPM, you'll need to set the API key in your app's entry point, and/or framework error-handler hook. For example in Vue.js

Make sure the API key has been set, so that we know the event was sent from you!

With the JS provider, you also need to make sure Crash Reporting and Real User Monitoring have been enabled.

    rg4js('apiKey', 'Paste your API key here, or retrieve it from configuration');
    rg4js('enableCrashReporting', true);
    rg4js('enablePulse', true);

Common gotchas:

  1. API key is missing or incorrectly added (fat-finger/copy-paste fail)
  2. You added the API key to the wrong section of your configuration (e.g., not in the client side config section)
  3. Your Automated Deployment process is incorrectly updating the API key
    1. Has not been added to your deployment secret store
    2. Has configured for the incorrect environment or role
  4. The API key setup is in the incorrect part of your app, so is not getting called on load/app start

It's often useful to trigger a known test event to demonstrate that everything is in place.

For Real User Monitoring, shortly after you start navigating around the web page, events should start being sent to Raygun and become visible on the Real User Monitoring tab.

For Crash Reporting

In the browser, open the developer console and run something like:

rg4js('send', new Error('This is an error from the console'));

Or, add a button on the page like this:

<button onclick="throw new Error('This button is faulty')">Send Test Error</button>

On the server side, try adding a testing endpoint, something like this:

    [RoutePrefix("test/error")]
    public ActionResult Testing()
    {
      throw new NotImplementedException("Send a test error on the server");
    }

or

    [RoutePrefix("test/error")]
    public ActionResult Testing()
    {
      _logger.LogError("Logging a test error on the server");
      return View();
    }

For other platforms or frameworks, see the relevant documentation.

To state the obvious: Unless the events get delivered to us, we can't display them to you.

If you've sent a test error and waited a moment for it to show up but nothing has appeared, you may want to check there are no blockages in the pipes.

In the browser:

Open Developer Tools, Network tab, Filter for fetch/xhr requests sent to https://api.raygun.io/entries or https://api.raygun.io/events

If you're getting something other than a 200, 201, or 202 response, then drill in to the details of the response to see what's causing the issue.

On the server side:

  1. Check that messages are being passed correctly from any logging framework to the Raygun provider
  2. Send a test event to Raygun using a tool like Curl or Powershell Example script
  3. Debugging on a local instance
  4. Use a network tracing tool like Wireshark

If you don't have access to your production servers, then one of your infrastructure engineers can run a Curl or Powershell script. This can be very useful for discovering networking or firewall issues, or if you need to set up a proxy configuration.

For APM, please see this APM troubleshooting guide

If you're still having trouble, please see this additional Crash Reporting resource Or get in touch with support@raygun.com. We're more than happy to help you get up and running.