Fix ‘Script Error’ and get the most data possible from cross-domain JS errors

If you’re working on a website and have Raygun hooked into its client-side JavaScript, one of the first things you probably noticed was the rather unhelpful “Script Error” appearing in your dashboard. You may have also seen this appear in the browser console while developing, and noticed that Script Errors are thrown when errors from scripts loaded from a different domain than the origin are caught by the global window.onerror handler.

Browsers may behave in this way as a security feature to protect against potentially malicious scripts injected or hosted by other sites from reading user data such as cookies (quite rightly, I’m sure you’ll agree). This is termed the Same-Origin Policy, and means that scripts only have full access rights if they are loaded from the same origin domain as the original document (when the script passes the CORS validation).

The Same-Origin Policy

CORS and the Same-Origin Policy do however present a problem with regards to the architecture of modern web sites and applications. Due to the nature of HTTP 1.1, frequently key resources including JavaScripts are hosted on non-origin (also called ‘third-party’) domains – in particular CDNs, as using the massive resources of public clouds keeps both costs and response times low. The main problem is that if your web application code is defined and loaded in a script hosted on a different domain to the one in the address bar, errors that hit window.onerror won’t have any stack trace or message context for you to debug. This is not a problem when developing locally, but becomes a critical issue when trying to figure out why a site is breaking on a user’s machine. This is most obvious when Raygun4JS reports these errors, and the error groups lack any indication as to what happened.

The spec and implementation for controlling the Same-Origin Policy is documented nicely here. In particular the Browser Compatibility matrix is a valuable read; you’ll notice proper implementations are only available in recent versions of the evergreen browsers, come with caveats in the bug tickets, or are plain not supported.

There are two key pieces of metadata needed to allow a cross-domain script to report errors correctly in a modern browser. As the documentation lists above, the first is the presence of the ‘crossorigin’ attribute on the appropriate script tag. By example:

The second critical bit of data is the presence of an HTTP header on the response from the third-party domain containing the JavaScript. This is:

The wildcard in this example allows all sites to report errors with full data, and is appropriate for a CDN where the script may be requested by any third-party domain. If this is a private host for a known set of domains, you can provide that list in place of the wildcard.

Different browser behavior

Depending on what browser your users are running, the above properties may or may not have an effect. This sums up the situation as of writing:

  • Chrome 30+
  • Firefox 13+
  • Opera 12.50+
  • Safari (at least 6+)

In these browsers, if the script attribute is present, the HTTP header will need to be also present, otherwise the script will be blocked.

Firefox has additional behavior for RuntimeErrors. These will be provided to window.onerror regardless of the two properties, as apparantly these aren’t considered a security risk. Syntax errors, however, will be blocked in both Gecko and WebKit browsers, if crossorigin is present but the associated cross-origin domain lacks the header.

  • Internet Explorer <= 10

Errors will be reported with all available data in IE 10 and below – now considered a security issue.

  • Internet Explorer 11+

Third-party errors will not contain any data, and the attributes are not respected at current time – we’re hoping that Microsoft Edge will resolve this.

Ready to blast errors

Like many elements of software dev, there are pitfalls to be aware of when it comes to security and legacy platform support. CORS support and third-party errors are just one of these, but hopefully with the above guide you should be able to ensure you are receiving the error data you need to fix bugs on your cross-origin scripts, while guarding against malicious third-party scripts and script injection.

Got questions about this post? Let us know in the comments section below. If you haven’t tried out Raygun, see what the buzz is about by starting your free 30-day trial here, no credit card needed.

Share this post

JavaScript debugging made easy with Source Maps

Source maps are a useful tool for debugging and fixing minified JavaScript code without the hassle of determining where in the original code an error occurred. They provide a way to translate between minified code, designed to decrease webpage load times to the source code the developer writes.

This post gives an overview of setting up and using source mapping in your browser as well as within Raygun.

If you’re unfamiliar with source maps it’s probably best to see how they work within the browser. You can read about how to generate source maps here.

Source Maps are natively supported by both Google Chrome and Firefox as well as IE11, this means that any minified JavaScript files with a source map comment at the bottom will automatically link to its sources so long as the mapping and source files are in the correct locations.

This allows errors to be mapped onto the original source code instead of reporting errors on only the minified script.

For instance if a minified file example.min.js has the following comment at the end of the file

the browser will load the mapping file in the same directory as the minified file. Any source files specified by mapping file will then be loaded into the Sources window in the browser console.

In addition to showing the source files in the sources window, any errors which happen within the minified file will automatically be mapped into the source files allowing for easy debugging.

Now that you have an idea about how source maps can be used to review code and debug locally, here is an overview of how source maps can be used with Raygun to debug script errors reported from client’s browsers.

When an error occurs in the JavaScript of a website using Raygun an error report including stacktrace is send to Raygun.

Contained within the stacktrace are the URLs of the scripts in which the error occurred.

Given these URLs Raygun can download each script file and check for a source map comment. If the comment exists it tries to map the line of the stacktrace onto source code. This is done by downloading the map file specified.
If a map file is available Raygun can then perform the mapping which converts the lines numbers of the stacktrace on the minified code into line numbers on the source files, it also resolves the source files. Given the source file URL we make additional requests for the source files. If we can retrieve these we insert a snippet of the source code into the stacktrace to give context to the error.

All of this can be done across the public internet if the files are hosted at the correct URLs and are publicly available.

For many people hosting JavaScript files publicly is not in their best interests. For this reason Raygun provides a source map center, this is a private store of JavaScript files to be used in the source mapping process. It allows source mapping to work without hosting anything publicly.

If a file is uploaded into the source map center it will be used instead of requesting a file from the internet. All that is required is that the file be labeled with the URL it would be accessed from if it were to be publicly hosted. In most cases this is easy to figure out. For minified files it’s simply the address your minified files are served from. The address of the map and source files may be a bit harder but can usually be figured out by looking at the relative URLs in the generated sourceMappingURL comment in the minified files as well as the sources section of the map files and figuring out the absolute URL based on the address of the minified files.

Hopefully this post has given an overview of how Raygun can be used to produce powerful error reporting for minified JavaScript code in production environments.

Want to see this in action with your own apps? Raygun has a free trial available. Get started today and start blasting away software errors in record time!

Read the full documentation about how to set up Source Mapping in Raygun in the docs.

Read here about enabling source map debugging in Google Chrome  and Firefox.

Share this post

Fixing Xamarin Errors Once Your Mobile App Is In The Wild

No matter how much time we as developers spend testing our apps, there’s always an edge case that we can’t possibly think of – and sure enough it’s always after it’s approved in the App Store! When your app crashes, your customers don’t have the best experience – there’s nothing worse than trying to use an app that crashes constantly. That’s where having a good error tracking solution like Raygun can help you get insights into your Xamarin applications once they’re in users hands.

By accurately tracking which devices are throwing what errors and where they’re coming from, you can can quickly fix them and get your app back in the Apple approval queue and in the the arms (phones) of your waiting customers. If you choose to enable user tracking, you can even contact people directly and let them know that a fix is on its way. How’s that for customer service?

smartphone 2

Because of the delay in getting App Store update approval, I generally follow a two week release cycle for non-critical issues. This allows enough time to get all those little bugs fixed from the previous release as well as building new functionality.

Once your app has been approved and people are actively using it, you will start receiving exception data in Raygun. I generally choose to solve the most common issues first, so in Raygun I order by count and look through the most troublesome issues, as they will be affecting the largest number of users.


Here we can see there was an exception adding a task – looks like someone didn’t put a value where it was needed. By using the stack trace I can fire up Xamarin Studio and see exactly where the error is occurring, and based on the method that’s being called, reproduce it in the simulator myself.

Sometimes though, no matter how hard you try, you can’t reproduce the error. Maybe your customers device is slightly different? Or there’s another weird issue on their end. Assuming you’ve set up User Tracking, you have user details right there! Time to flick them an email asking very nicely if they can describe the steps they took when your app crashed. Most people are happy to help and will provide you with detailed steps and appreciate that you care about their experience, keeping them coming back, even when things don’t quite go right.

Once you’ve tidied up your exceptions, it’s time to submit an update to the App Store! While Apple is doing their thing, you can start working on your next feature to get your users super excited.

Want to see this in action with your own apps? Raygun has a free trial available. Get started today and start blasting away software errors in record time!

Share this post

Creating A Deployment Tracking Workflow With Raygun

Here at Raygun, the development team use Raygun, on Raygun itself. I guess when you’re developing the best error reporting solution on the market, you should use your own product to identify bugs, so we often see a software error report inside of Raygun, that’s been identified by Raygun and sent to Raygun. It’s kinda cool.

We use Raygun’s Deployment Tracking feature internally to identify problematic deployments and triage errors. Personally, I use it see what other errors first occurred in, or reoccurred in, a deployment, which gives me a better idea of the root cause of bugs that cause multiple (different) exceptions. I’m getting a little ahead of myself though; so I’ll run through how we have the system set up first, then explain how we use each of the features.

Getting deployments into Raygun

Raygun uses Octopus Deploy to push our code to the production environment, but we have support for the most popular deployment tools on the market. For the website project, our deployment process is the following:

  1. Deploy the Raygun.Website package to the “web” machine group
  2. Register the deployment in Raygun
  3. Tag the deployment in Teamcity
  4. Notify the team in Slack that the deployment succeeded/failed

We register the deployment in Raygun using a Step Template – there’s more information on how to set this up in the docs for Octopus Deploy. After the first deployment step has succeeded, that Powershell script will send a JSON payload to Raygun that looks something like this:

This gives us the following deployment in Raygun:

Deployment Tracking

Using deployment tracking for release management

Once the code is released, we play the waiting game. An hour later as I’m sitting down to have my lunch: disaster strikes! A new error has occurred, and Raygun has emailed me about it. The deployment tracking endpoint is failing to validate the email address people are sending us! I check out the error page – looks like someone sent us a deployment with no email address. That should be fine…

The Commits tab on the Deployment page can help here by showing us what commits were released in this deployment.

Deployment Commits

Oh. I added that fancy email validation regex, and must have forgotten to add an empty check before it. Whoops. The Commits tab links through to each of the commits on Github so I can see the code that changed in that commit, and easily find it again.

I fix the problem, and while the build is running I go back to the error and mark it as Resolved in Version This means Raygun will stop emailing me to say the error is still occurring, unless the version is greater than or equal to Once the build is done and deployed, I can jump back into Deployment Tracking and see that the new release is doing a lot better.

Deployment Tracking

It really is that simple to create an awesome workflow surrounding errors and deployments, giving you peace of mind that each release is tracked and associated errors identified. Deployment Tracking can tell you which errors have been introduced with the new release, which are still occurring and which have been fixed. That’s why Raygun is the essential tool in every software developers toolkit.

Want to give this a go yourself? Raygun offers a free trial, so no excuses, get started today!

Share this post

Raygun Wins At The 2015 NZ Hi-Tech Awards

Mindscape Limited, the creators of Raygun, are pleased to announce another award! This time it was the New Zealand Venture Investment Fund Hi-Tech Startup Company of the Year. This follows on from the awards Mindscape picked up in 2014.


The awards night event saw companies win awards in a range of categories, congratulations to everybody that was nominated. It was a pleasure to be there alongside some of the country’s top tech talent.

0450-high-tech2015 2

(Picture: Some of the New Zealand Raygun HQ team. We’re sure the San Francisco office are just as proud, even though they were not with us on the night.)

Moments like this are always a highlight for us as we continue working every day to bring you the best developer tools possible. It’s a great testament to our team and we’d like to thank all of our awesome customers, friends, family, investors and everybody else that has supported us along the way. We’ve shrugged off the hangovers, paid the bar tabs, caught up on sleep and for now, it’s back to work!

Share this post

Getting Started With NLog and Raygun

NLog is a brilliant logging system that has been around in the .NET world for a while now. It’s useful in generating debug log files and spitting out exceptions. The biggest issue is that exceptions can get lost in all the text, and they’re hard to track. Now you can push exceptions straight from your existing code into Raygun.

We have just forked and updated NLog.Raygun, which provides a Raygun logging target for you to use. You can find it here.


Setting things up

You’ll need to checkout and build the code yourself, storing the DLL in a shared place for your projects.

Once you’ve included the DLL in your application, you need to add the new target to your NLog.config file. We recommend only listening for errors and above so you don’t end up with lots of debug messages in Raygun.

First, add NLog.Raygun to your extensions

Then setup your target, remembering to set your API key and any tags you want.

And last but not least, setup the rule to actually log to the Raygun target.

Now any exceptions that you’re logging will go to both Raygun and your other targets! Simple.

Share this post

MADTampa Recap – Improving Your App Quality With Raygun Error Reporting

This week Russ Fustino spoke to attendees at the Mobile App Developer (MAD) Group meeting in Tampa, Florida. This session had lots of interest about “Improving Your App Quality”.


Some of the questions that were asked at the event:

Q: Can I use multiple technologies for an application and consider it one application in Raygun? IE, if I have a hybrid app with Xamarin written in C# that uses a Web page with JavaScript, can I use the same App ID both both?

A: Yes. You can combine technologies for an Application as defined in Raygun. We just use language choice to get you started when you create an app.  Of course, an application is how you  feel all of the necessary components that add up to make up your app run. Raygun pricing is not based on multiple languages or technologies that are used for the app.

Q:  How long is the trial period for Raygun?

A: 30 Days

Q: Can I capture non-error information with Raygun?

A: At this time, you can collect affected user information associated with errors.

Q: How do I manage an app in test versus an app in production using Raygun?

A: The simplest way is to have a separate app ID for Production, You can easily do this with conditional compilation statements DEBUG vs RELEASE compiles in Visual Studio.


Here’s Russ’ slides from the event:

Three completed sample projects I demonstrated for setting up Raygun are here for JavaScript, WPF and Xamarin Forms using Dependency Injection.

Some useful plugins for Xamarin (Device, Settings, etc..):

Affected user tracking:


.NET Platforms:

Language support:



Raygun blog:

Case Studies:

Dependency Injection:

Contact info:



I hope everyone that attended enjoyed the event! Or, if you weren’t at the event, I hope the above slides, sample projects and links are useful to get started with Raygun today!

Share this post

Javascript Debugging With Black Box

At the end of 2013 Firefox launched a tool called Black Box to their browser inspector. About a year later, Chrome did the same. If you don’t know about black boxing scripts but you need to carry out Javascript debugging in you code, you should definitely give this post a read.

What is Black boxing?

Black boxing allows you to disable scripts for debugging, so you can focus on debugging the scripts that are relevant. E.g you are debugging Javascript a Backbone/Marionette app which is using underscore and jquery under the hood. Most likely you have a bunch of other favorite plugins/libraries/frameworks. When we debug, we most likely don’t want to debug all those vendor scripts. Most of the time we just want to debug our own scripts or maybe just some of them. And this is when black box comes in handy. We can black list all scripts that are not relevant for this debugging case.

How would we normally do it?

We would click through the code with the buttons

Debug buttons

  • step over next function call
  • step in to next function call
  • step out this function call

That works fine, but…

Every time we click we have to think. “Should I click step-in-to or step-over?” The same question could in many cases be – “Is this a vendor function or is it a function I wrote?”
Next line. We have to ask the same question again. So if you’re stepping through 10 lines, you have to chose between step-over or step-in-to 10 times. If you do this debugging procedure 10 times you have to ask the question 100 times. I guess you see what we’re getting at. It’s a minor thing that you have to do very often. How annoying.

With black box we can make this decision beforehand. What scripts are not relevant for this debugging? Black box them and you don’t need to worry about stepping in to irrelevant functions. A common usage would be to black list vendor scripts for instance jquery, backbone, marionette and underscore.

Let’s make an example

The following example will demonstrate the difference of debugging with and without black box.

On click of the body element, we’re fetching two elements from the DOM. One of them is undefined. We pass the elements to the function foo, and then we calculate the length on them. Since one element is undefined on line 11 it will cause an error. This is the bug we want to hunt down as quickly as possible.

Since I don’t want to debug inside jQuery I will black list it. Now the the step-in-to button becomes something I would like to call step-in-to-if-relevant. In this case I can use step-in-to all the time without the worry of ending up in jquery scripts.  Even though I click step-in-to, the debugger will do step-over on line 16,17 and 10,11 since they are jQuery functions.

How do I use it?


– Alt 1. Go to source in the inspector. Right click the file you want to black list and choose black box script.

– Alt 2. Click on the cog to open up the settings view. Click the button “manage framework black boxing”. In the new pop up you can write a regexp as a path. This is great if you for example want to black box the entire vendor folder.

Read more here.  


Go to the debugger tab in the inspector. Mark the script you want to black list. Click on the eye in the very bottom left corner.

Read more here


This feature makes it much easier to keep your debugging in the right scope. I hope you found this article useful and it saves you some time! Want to get notified of your Javascript errors in real-time when users run into them. Try Raygun free today!

Share this post

Performance Showdown: Node.js vs. io.js v2.0.0

We noted with some interest the recent announcement of the io.js v2.0.0 release candidate. This community fork of node.js promises a supported version of the V8 engine, along with a greatly increased frequency of commits to master vs. the parent project.

As we’ve mentioned before, we’re keen on these developments as Node.js powers the Raygun API nodes, and ensuring these can handle the highest loads with the lowest possible response times is crucial to providing a great service to our users. A previous blog post benchmarked Node.js vs. io.js, and with the advent of the V2 release of the latter, we’d like to revisit those benchmarks to see how it stacks up in various situations.

node-vs-io 2

The set up

Same as before, the following are synthetic micro-benchmarks, caveat emptor, huge grain of salt, etc. However, the charts do provide some interesting food for thought, and may provide a springboard for you to perform your own real-world tests, and potentially gain a significant speedup.

The benchmarks were conducted with identical runs through ApacheBench on a 64-bit Ubuntu VM. The configuration was 20,000 requests with a concurrency level of 100, and the test results were averaged over five runs of this.

We benchmarked two versions of node, and two versions of io.js. For node, v0.10.38 (the last release of the .10 branch) was compared against v0.12.2 (the absolute latest version of node.js).

For io.js, we compared v1.8.1, the last release on the 1.x branch against the newest v2.0.0 release.

Raw JSON response

This test involved created a simple server with the http module, and setting it to return a JSON payload on request. The results were:


What is interesting to note is the performance drop from node 0.10 to 0.12, which io.js corrects on the 1.x branch – but then dominates with v2.0.0.

When sending a raw response, in this benchmark io.js v2.0.0 has a 14% speedup over node 0.12! They’ve even managed a 5% speedup over their own previous release. Not bad at all, but there’s more we can test.


Express was and is still a very popular choice for quickly getting the backend of a web application up and running. Last time we documented some of the performance hit you take with it, but let’s see how it does under node 0.12 vs io.js v2.0.0:


There’s a 4.5% speedup when running this test on io.js v2.0.0 – pretty good for an older framework (considering how fast the JS ecosystem is moving)!

Koa.js on Node vs io.js

Many newer frameworks are competing for mindshare in the JS micro web framework space, however – we benchmarked some popular ones previously. One which we missed was Koa.js, which was in fact made by the authors of Express.js.

One of the huge benefits with Koa is that you can build code using ES6 features – including generators and the yield syntax which enable asynchronous code (no more callback hell). This benchmark was written using generators and run with the node --harmony flag enabled. The logic involved a simple bit of routing, and set the response to be an HTML fragment.

Let’s see how Koa does running on Node vs. io.js:


A 14.8% speedup from Node to the latest version of io.js – certainly worthy of note. If you’re looking at one of the latest generation of JS backend frameworks, it certainly pays to give io.js a look as out-of-the-box you get some rather impressive perf improvements. When running a cluster of VMs using the Node stack, depending on scale, that speedup may result in several fewer boxes needed and correspondingly less infrastructure costs – all for free.

We do error tracking

We love perf improvements here at Raygun, so if you have any experience running io.js or Node in production feel free to post in the comments. We also have a kickass Node error tracking implementation – there’s a free 30-day trial available here. Keep improving that perf, and blasting those errors!

Share this post

5 Tips For Writing Great Software Error Messages

In this post I’m going to talk about software errors/exceptions and how you can craft better software by giving them appropriate design considerations. I’ve often found that developers, even experienced developers, don’t put much thought into the error objects that they produce.

This article is designed to be language agnostic, just like Raygun itself. I use ‘error’ and ‘exception’ interchangeably and mean the same thing.

1. Be specific

When an exceptional situation occurs and you wish to throw an exception for that state, what type of error should you throw?

When I was a junior developer, I’d frequently find an existing exception type and just use that. A common example was ‘ArgumentOutOfRangeException‘ because that often was the error that had occurred – a method had received a parameter that was outside of the bounds for whatever I was doing. That’s totally fine for simple exceptions like a legitimate out of range exception.

Outside of the lower/simple level, say, in your business logic or domain model, I’m a big believer in writing your own exception types.

It is fairly straight forward to quickly create your own exception types in most languages. The base type for an exception is fairly deeply built into any language and usually you can inherit from that to implement your own types.

2. Great software error messages

With Raygun, we’ve literally seen billions of errors reported to us. We’ve seen the good, the bad and the ugly of software error messages.

A common reason for bad messages, is that we developers like to load the context into the error message. For example, we won’t typically choose to throw an exception with “User not found.” as it doesn’t help us debug in a hurry. We’ll throw “User not found:, id: 2133″, giving us context on the error right there in the message.

While that seems helpful, it is not a wise idea.

Firstly, it leaks implementation details to any users who might see the error message.

Secondly, there’s only so much context you can squeeze into the message.

Thirdly, there is a better way…

3. Use error properties

Two options exist here. Remember my suggestion that you create your own exception types? This is where it shines.

You can simply add properties to your implementation that states properties that matter to you. Perhaps it’s attaching the user data, the SQL query that failed, or the primary key of a domain entity that was involved in the error. Easy.

The second option, which is a little more language specific, is data dictionaries. Take for example the .NET framework. The Exception base type has a ‘Data‘ dictionary property. You can load in any contextual information in that dictionary to be provided alongside your error – nice!

4. Only use exceptions in exceptional cases

This is more a general rule, but exceptions are supposed to be exceptional. They break control flow making it difficult to understand the repercussions of an exception. That means it can be hard for other developers to understand your code.

Further making this worse, exceptions are often treated in special ways by the host runtime. In managed languages like Java and .NET, an exception causes the entire runtime to do a lot of work — building stack traces, running a bunch of tasks to handle the error and more. This all leads to performance implications if you’re throwing too many exceptions.

Exceptions should be exceptional.

5. Do something with them

OK, so this one is a bit cheeky – but if you do have errors being thrown, you want know about it.

That’s exactly why we built Raygun in the first place: so you can see the health of your apps, and then fix things. Not a Raygun user yet? Well, luckily we have a free 30 day trial. Try it out for yourself!

Share this post