Pricing question
stevenwright
Posted on
Oct 09 2013
Hi,
I'd like to clarify some questions on pricing.
We provide software that our customers install on their sites, our single software package runs as three Windows service, an administration client, and either some Java extensions to another package or a DLL extension for Windows NPS.
What licensing would we need for Raygun? Should we license for one software package, count the number of separate executables we have, or count the number of customers who will run our software package?
Thanks Steven
John-Daniel Trask
Raygun
Posted on
Oct 09 2013
Hi Steven,
It sounds like you & your team are the only folks that will be monitoring the errors? In that situation you'd only need the one Raygun account for your organisation.
It sounds like your application is made up of several moving parts - sometimes written in different languages. What we typically recommend for this (and do ourselves) is to use a different Application API Key per part (e.g., you will create an 'app' for your Windows Service, one for your 'Administration Client', etc). This helps just group where errors are coming from nicely.
With that in mind it sounds to me that you'd be best to pick a single plan for your organisation. One of the top three plans (the smallest plan is more targeted at hobbyist and only provides for a single application to be monitored, it also doesn't provide team and organisation features).
I hope that helps with understanding how the model would work for you. Do let me know if you have any further questions I can help with.
John-Daniel Trask
Co-founder
Mindscape Limited
stevenwright
Posted on
Oct 10 2013
.>It sounds like you & your team are the only folks that will be monitoring the errors?
Yes - we'd be the only ones monitoring via Raygun anyway. Our software runs on customer's servers and they'd monitor local log files as normal, what we hope to get from Raygun is a) an awareness of issues our customers haven't yet reported, b) metrics for the number of customers impacted, c) reports of issues in a standardised format with enough information to either resolve the problem or have a very good idea what is happening.
.>What we typically recommend for this (and do ourselves) is to use a different Application API Key per part (e.g., you will create an 'app' for your Windows Service, one for your 'Administration Client', etc). This helps just group where errors are coming from nicely.
Ok - so we could initially take the five application pack you offer and run that on several hundred customer sites each reporting errors. That sounds good. What happens when we release a new version? Taking the 'Administration Client' as an example there will likely be X number of releases over the coming year with bug fixes and new features, as customers won't all upgrade at the same time how will we know which version is reporting the issues? Will we need one API key per version (that could become expensive) or can we record the version somehow and filter on it?
Thanks for the help so far.
John-Daniel Trask
Raygun
Posted on
Oct 10 2013
Hi Steven,
The Small plan that supports 5 apps would work well.
With some of our providers (e.g. .NET provider) we interrogate the executing program and find the version running and report that in the payload to Raygun. We don't do this for certain platforms (e.g. PHP or JavaScript) since there's no version information to automatically collect.
I'm thinking we should add something like a method to set a version (raygunClient.SetVersion('1.2.2.2') sort of thing) in those languages that don't figure out the version.
The reason for this is that we're working on allowing dashboard filtering to only show issues in a particular version. This is a common feature request and something we want ourselves for monitoring our other products. This way we can focus more on the bugs in the latest releases.
This would help you as well and mean you can stick with one API key per app, irrespective of version.
I'll discuss this with the team and see what sort of timeline is needed to support this. We already have the backend part nailed but we'd need to have it work across all languages + surface a nice UI for picking the version.
Out of interest, what are all the programming languages you'd be looking to integrate with? We can tackle them first in updating the providers :-)
I hope that helps,
John-Daniel Trask
Co-founder
Mindscape Limited