2016 Recap - Let there be STATS!

Exceptionless 2016 in review

We were curious, so we thought we would put together some stats for 2016, along with and a recap of some of the notable changes and progression. Enjoy!

General Exceptionless Stats #

  • Over 120,000,000 events processed
  • 4716 users
  • 3614 projects
  • 2809 organizations

Release Stats #

Exceptionless Server: #

  • 7 releases
  • 88 watching
  • 774 stars
  • 236 forks

Exceptionless UI: #

  • 6 releases
  • 9 watching
  • 38 stars
  • 34 forks

Foundatio: #

  • 4 releases
  • 65 watching
  • 472 stars
  • 97 forks

Judging by the traffic to these posts and updates, they're all worth a read. Check them out!

Notable Changes / Milestones #

Server License Changes #

We changed the server licensing to use the Apache license. Now, every Exceptionless project is under the Apache license and there should be no more confusion on how it's licensed. Read more here.

Session Tracking & Management #

The ability to track and automatically manage a users session was added, giving you visibility into how long and what a user did while they were using your product. This also answers the question, "what did my users do leading up to this exception?" Read more here.

Fixed by Version #

In 2016, we also added the ability to mark an event as fixed in a specific version of your app. Read more here.

Performance & Reliability #

We spent a lot of time this past year making massive performance and reliability improvements across the board. Tons of bugs got fixed along the way, and additions like bulk updates and deletes, along with optimized query generation got squeezed in there, too! One big factor here is that it has allowed us to move to Elasticsearch 5 much quicker because all of these improvements allowed us to do things more generically throughout. Much less code to update/change!

Elasticsearch 5

Like we mentioned above, we've done a ton of work to ensure we can move to Elasticsearch 5:

  • Insanely fast document indexing and searching
  • Dynamic aggregations (allowing us to do completely customize stats on any data)
  • Reindexing support
  • Daily indexes
  • Making it easier to self host
  • Getting one step closer to server being able to run cross-platform

We have been doing QA on the Elasticsearch 5 migration since the end of the year and it is currently still in progress - coming soon!

Open Source ALL the Things #

We open sourced two major new libraries this year:

  • Foundatio.Repositories
    Foundatio.Repositories are generic repositories with an implementation for Elasticsearch
  • Foundatio.Parsers
    Foundatio.Parsers are Lucene query parsers that allow you to validate or modify Lucene queries with ease!

Other Noteworthy Enhancements #

Onward to 2017 - Stay Tuned for a Roadmap! #

We've got big things coming up, like Exceptionless 5.0 with Elasticsearch 5, which should boost performance gains like 80% faster indexing, lower memory usage, and native reindexing support! No slowing down over here, so stay tuned and enjoy the ride.

And, as always, if you have anything you'd like to see in upcoming Exceptionless releases, please let us know!

Exceptionless Helps Identify Issue Affecting 25,000 Users - Case Study

CEVO, Inc. LogoCase study time!

Today we've got a great example of Exceptionless helping software developers identify major issues in their web applications affecting thousands of users.

In this case, the problem was major enough that the development team stopped using WPF and rewrote their entire UI layer!

Here's what Will Graham, CEVO, Inc. developer, had to say when we asked him a few Exceptionless case study questions.

Exceptionless Case Study - CEVO, Inc. #

What’s the number one customer-facing bug Exceptionless helped you squash? #

"The issue was so prevalent we completely ditched WPF and rewrote our UI layer in GDI+/WinForms" - Will Graham, CEVO, Inc


Definitely crashes related to .NET Framework installation corruptions on end-user machines. While Exceptionless didn't (and can't) immediately point and say, "here's how to fix it", it did shine light on an issue that was affecting approximately 5% of our 500,000 installed base. The issue was so prevalent we completely ditched WPF and rewrote our UI layer in GDI+/WinForms, but Exceptionless gave us insight to see the problem and how many users were being affected.

Were you surprised at the initial results of using Exceptionless for the first time? How many errors were you seeing? #

"Exceptionless has changed our internal development process and how we approach code. Proper error handling and visibility is now a first-class priority for us and Exceptionless makes it super easy." - Will Graham, CEVO, Inc


Yes and no. Error handling and tracking had always been more of an afterthought - like, something is wrong, we need to look into it now. We weren't aware of issues until after our users reported it and filtering out the noise to find the signal of real issues was a time consuming process. Running on the Azure stack, we were frustrated with the information provided in the default diagnostics logging.

When we added Exceptionless, we knew we had problems with our system, we just didn't know where and to what extent. To be honest, Exceptionless has changed our internal development process and how we approach code. Proper error handling and visibility is now a first-class priority for us and Exceptionless makes it super easy.

What is the number one internal bug you were able to track down with Exceptionless? #


The biggest bug would have to be intermittent failures on our Service Bus instance. Using the metrics provided by Exceptionless, we were able to spend time implementing fault tolerance in very focused areas of the code based on incidence rate and end-user impact.

If you had one feature you’d like us to add to Exceptionless, what would it be? #


I'm not a huge fan of the current dashboard. It's effective, but with the amount of data Exceptionless has at it's disposal, I feel there's more interesting (and actionable) information that can be shown.

We Love It! #

Thanks for your time, Will! We love to hear from our users, and we'll definitely take that dashboard feedback and see what we can do there to make it more useful.

Do you have feedback on Exceptionless? Has it helped you find bugs and beat them into submission? Join us in the Exceptionless Discord and let us know!

Set Application Version for Improved Regression Notifications and Stacking

versioning(/assets/versioning.png)Do you get annoyed and overwhelmed by event and error notifications?

You probably have more than one version of your application running, and often older versions of your app may still be triggering events that have been fixed in newer versions.

**Those events and notifications aren't very **helpful, so we implemented a versioning system that allows you to set an application version on all events!

After setting an application version, when you mark an event fixed and give it a version number, it will only regress if it occurs again in a newer version of your app.

That means there is less noise for you to wade through, and you can focus on new issues in your application without seeing old or non-relevant events constantly.

How to Set an Application Version #

Setting an application version in Exceptionless is easy. By default, we attempt to resolve one automatically based on assembly attributes, but we recommend specifying one yourself for improved reliability and accuracy using the following examples.

.NET Version Specification Example #

using Exceptionless;

JavaScript/Node.JS Version Specification Example #


Fixed! #

Great! Now, when you mark an error stack as fixed and enter the version that you fixed it in, that event stack will have a Fixed In [Version] tag and will only regress if it occurs again in a later version of your app. If it does regress, the stack then gets the REGRESSED tag.



If you would like to view fixed events, you can always use the * wildcard or fixed:true in search.

We hope you find this feature useful, and as always don't hesitate to leave us feedback over on GitHub or by commenting below.

Real Time App Configuration and Event Settings with Exceptionless


Bet You Didn't Know Exceptionless Could Do This... #

Have you ever needed to cut through the noise and just focus on one type of event (in real time), such as only error logs, to track down a bug?

Do you want to limit certain types of event reporting (in real time) to save your event quota and limit clutter?

What about controlling your application's settings or features in real time via Exceptionless, without having to update your files and deploy your app!?

Well, with our client configuration settings, you can do all that, and more, in real time, on a per-project basis via your Exceptionless dashboard!

How Could This Help Me? #

We'll talk details, below, but first lets look at a few scenarios where the above could be useful.

Scenario 1 - Way too many events! #

Let's say you're on the small plan, and you've got a bunch of warning log events clogging your system that you know about and are working on, but they are pushing you over your plan limits.

#BOOM - set a minimum log level of error, and Exceptionless won't report those warnings anymore and they won't count against your plan limits! This is a great way to get the most out of your Exceptionless plan.

Scenario 2 - This Authentication Issue is KILLING Me! #

Maybe you're having major issues with an authentication bug, but you've already set minimum log levels to only include errors. Well, now you also want to see the trace values for those events without opening the flood gates for every event by removing your minimum log level.

#NOPROBLEM - Just add a key for authentication that just lets trace events through!

Scenario 3 - You Said Something About Controlling My App's Features In Real Time? #

Yup! Our client configurations are basically just a key value pair dictionary, but what makes them powerful and helps them control your application's features is that they get updated in nearly real-time, meaning you can build settings, features, etc into your app that react to value changes, and if you change that configuration setting in Exceptionless, your app will react almost instantly!

This can be super useful, especially if changing your app's settings would normally require you to deploy to production. No need - just use Exceptionless!

Primer: How Project Settings Work #

First, settings updates do not count towards plan limits. We say that because each time an event is submitted, we send a response header with the current configuration version to the client, and if a newer version is available, it is retrieved and the latest configuration is applied. That means that config changes are nearly real time.

When the client is idle, we also check for config changes, including five seconds after client startup if no events are submitted at startup, and every two minutes after the last event submission.

If the version hasn't changed, nothing is retrieved, limiting data transfer, and no user information is ever sent when checking.

Turning Off Automatic Updating #

If you do not want the configuration settings to update when idle, you can turn off automatic updates. To do so, please follow the respective .NET or JavaScript/Node.js documentation.

The Main Event: Client Configuration #


Exceptionless client configurations are a dictionary of key value pairs that can be used to control the behavior of your app in real time by doing things like controlling data exclusions, protecting sensitive data, enabling and disable features, or disabling certain types of events (error, usage, log, 404, or session).

We also have some built in configuration key naming conventions (@@EVENT_TYPE:SOURCE) that the clients recognize for ignoring events based on event type and event source. Just replace EVENT_TYPE part with the event type (E.G., errorlog...) and the SOURCE (E.G., exception type or log source) you'd like the setting to apply to. Next, specify key value of false to discard matching events client side. It's worth noting that  log event types can also accept a log level value (E.G., TraceDebugInfoWarnError, or Fatal).

For example, we can use it to turn off all error events of type, lets say, System.ArgumentNullException, by using the key @@error:System.ArgumentNullException and the value false.

Or, we could turn off all error events entirely by using the * wildcard. So, the key would be @@error:* and the value would be false again.

Examples for the Above Scenarios #

Scenario 1

In scenario 1, above, we were trying to save our plan limits by limiting log events to only errors. So our Client Configuration key would simply be @@log:* with value Error.

Scenario 2

Here we already limited our log events to errors, but now we're troubleshooting a specific issue with authentication (let's say we're using the AuthController API), so we want to look at the trace messages coming through. We can override any general minimum log levels that we've defined by setting a level for a specific log source. So, all we would do is add the @@log:*AuthController key with value Trace! Then, when the bug's fixed, turn it off as needed.

Scenario 3

This is the cool one. Here you are wanting to, let's say, pass a value for a setting in your app that turns something on or off without having to re-deploy everything. This is super easy to accomplish all we need to do is create a setting which will control our feature! Let's assume we have have a feature flag to show a welcome screen. We will name this feature flag enableWelcomeScreen and create a new configuration setting respectively with a value of true (You can change this value at any time). These changes will be pushed based on the above "How Project Settings Work" section automatically, all we have to do is check the setting as shown below.

using Exceptionless;
// Check the configuration settings for our enableWelcomeScreen feature flag with a default value of false.
if (ExceptionlessClient.Default.Configuration.Settings.GetBoolean("enableWelcomeScreen", false)) {
// Show the welcome screen!
// Check the configuration settings for our enableWelcomeScreen feature flag
if (exceptionless.ExceptionlessClient.default.config.settings['enableWelcomeScreen'] === true) {
// Show the welcome screen!

Pretty cool, right!

For more details on client configuration, check out the Client Configuration Project Settings documentation. Specific usage examples can be found on the .NET and JavaScript/Node.js documentation pages respectively.

Other Project Settings You Might Find Useful #

General #


If you go to Admin > Projects in Exceptionless, you can choose the project you would like to edit the settings for. Each project can have unique settings.

The default tab is "General," which simply houses the project name and attached organization. Nothing fancy here - pretty self explanatory.

API Keys #

exceptionless api keys

This tab is where you can generate an API key for your project. Again, pretty self explanatory. Hit "New API Key" and one gets generated. For more details on API usage, check out the API Usage documentation on GitHub.

Settings #

exceptionless project settings

This is where you can set data exclusions, customize error stacking, and build in some spam detection to your project.

Data Exclusions

There are several use cases where you might not want to send some data to your Exceptionless project. This field allows you to enter a comma delimited list of field names that will be removed and not transferred to Exceptionless. The perfect example here is a password field, or other personal and sensitive data.

The * wildcard is supported in this field and can be used at the end (password*), beginning(*password), or on both sides (*password*) of the field name to further customize your data exclusion.

Error Stacking

Control over error stacking is another level of customization project settings allows. You can specify user namespaces or common methods to ignore. More details below.

User Namespaces

Here you can enter a comma delimited list of namespace names that own your application. With those in place, the only methods that will be considered stacking targets are ones inside those namespaces.

Common Methods

If your code has shared utility methods that may generate a bunch of errors, this could be useful. Enter a comma delimited list of common method names that shouldn't be used as stacking targets, and they will be ignored.

Spam Detection

Spam is the worst. So, we added a "Spam Detection" list of common user agents that should be ignored, which you can add to as you see fit. This eliminates a lot of noise, and can be customized to help trim even more depending on your application.

Along with the comma delimited list of user agents to ignore, you can also tick the box that says "Reduce noise by automatically hiding high volumes of events coming from a single client IP address." This can ward off large numbers of events being submitted by a spammer or attack on your app.


exceptionless integrations

Integrations with tools like Slack, HipChat, JIRA, Basecamp, and others are very popular and can add a level of automated notifications, etc, to your workflow. So, on the integrations tab of your project's configuration you can create web hooks to integrate with your service or others as mentioned. Each web hook has a URL that it can call, and options for when it should be called. When a selected event occurs, a POST request is submitted with either event or stack data in JSON format. For more details and sample data, visit the Exceptionless integrations documentation.

That About Covers It! #

We hope this will help you make the most out of your Exceptionless projects, allowing you to save some event submissions, get that customization you were looking for, etc.

Please let us know if you have any questions, comments, concerns, bugs, or anything else we can help with!

Exceptionless 3.4 - New User Dashboards, Job Reliability, and Bug Fixes

Exceptionless 3.4(/assets/exceptionless-3-4-header.png)

The latest Exceptionless release has several additions we think most of our users will find helpful. We sat down and worked on the UI, fixed some bugs, and spend a considerable amount of time improving reliability and efficiency of some of the primary pieces of the app.

If you're a self hoster, you'll need to upgrade your existing install, but if you're hosting with us there is no action required on your part to experiences the Exceptionless 3.4.

For more information about this release, take a look below and/or review the full release notes over on GitHub.

UI Updates #

These updates were all pushed with Exceptionless.UI 2.5 a few days prior to this release of the main app. Enjoy!

Search Wildcard #

You can now use * to show all events in the search box. Woohoo!

Most Users Dashboard #

The new most users dashboard allows you a quick view of events sorted by the highest number of affected users. This is great for helping prioritize your work pipeline.

Also, as an aside, we've added the users affected column to the dashboard. We know some of you guys will find that helpful.

New Keyboard Shortcuts #

MacOS & Linux keyboard shortcut support has been added, as well as additional shortcuts such as C to chat with support, S to focus the search bar, and g a to go to your account. Hit SHIFT + / (also known as ? ) to access the keyboard shortcut list on any screen.

As an aside here, there is also now a </> button near the top of the event occurrence that lets you quickly copy the JSON to your clipboard with a click.

Other Updates #

This is just a quick list of everything else we tweaked, updated, added, or fixed with the v2.4 release.

Performance & Reliability #

We made several reliability and performance enhancements to queue and job processing. A few specific examples include fixing auto-abandoned jobs and instances where batch events weren't being requeued.

Heartbeat API Endpoints #

Previously we had worked on making heartbeat events efficient so we didn't have to count them toward event quotas, and with this release we've added new API Endpoints that allow clients to submit those heartbeats cheaply.

Active Directory Authentication #

Support has been added for Active Directory Authentication. Thanks @laughinggoose! To enable this feature, head over to the Active Directory Authentication documentation page on GitHub.

Count #

This Count property was added to the event model that tracks deduplicated events and allows for some pretty cool metrics from here on out while avoiding the full cost of storing every event.

MaximumRetentionDays #

MaximumRetentionDays is pretty self explanatory. It controls the max retention perdiod for events, which allows the retention job and plans to be smarter about cleaning up old data.

Bugs #

SignalR (web sockets) support wasn't always working in some hosting environments such as AWS, so we fixed a few bugs related to that.

Exceptionless.NET 4.0 - .NET Core and ASP.NET Core Support!

That's right folks, with the release of Exceptionless.NET 4.0 you can now build .NET applications with Exceptionless on Linux, MacOS, and Windows!

We've added .NET Core, ASP.NET Core, and .NET Standard 1.2+ support.

We know many of you have been waiting for this, and it's been a long time coming, but we sat down, put in the hours, and made it happen for you guys!

Exceptionless on Mac OSX(/assets/Screen-Shot-2016-06-28-at-3.08.17-PM.png)

The NuGet package now supports .NET Standard 1.2+, PCL Profile 151, and .NET 4.5.

To make upgrading easy, the Exceptionless.Portable NuGet package still exists and is dependent on the Exceptionless Package.

If .NET 4.0 is a requirement for your projects, you will need to continue using the Exceptionless.NET v3.5 NuGet Packages, which are not being deprecated.

As a matter of housekeeping, we removed the ExceptionlessClient.Current property, which was replaced with ExceptionlessClient.Default in v2.0.0, and the configuration EnableSSL properties (also deprecated in v2).

Upgrading #

Updating the NuGet packages should be all you need to do if you are upgrading from Exceptionless.NET v2 or v3. Take a look at the upgrade guide if you have any questions.

Session Heartbeats No Longer Count Towards Plan Limits

session-tracking-revisedThat's right! We've re-imagined how session heartbeats and session end events should work on the back end and were able to make them much more efficient, allowing us to stop counting them toward user plan limits!

This blog post explains our original goals and implementation of these session events, and how we were able to retain the same functionality of the feature while limiting resource usage.

Our hope is that this will obviously make our users happy, but also that all the developers out there can benefit from our process and solution.

Genesis: Exceptionless Session Tracking #

In the beginning, we set out to create a sessions feature that allowed our users to submit a session start event and the session would be automatically updated by sending a session heartbeat event, as well as a session end event, respectively.

These session heartbeats and session end events were meant to be session markers to show that a user was active or a session had ended.

We wanted to leverage our existing infrastructure, and the easiest way to do so was to introduce new event types that we recognized. This meant that these events went through the client side plugins (extra work) and server side processing. As such, there was no way to tell these events apart from any other event.

And because of that, they counted against user plan limits.

Noise #

After releasing the sessions feature, it didn't take us long to notice that the heartbeats were noise. However, we knew that users wanted to see what their customers or users were doing while being active throughout the session, so we didn't remove them.

We knew they were counting towards plan limits, causing some users to reach theirs quickly, and we knew they were adding noise, thus limiting the feature's value, but we also wanted to keep the feature alive because of the potential value offered. So, we had to react and make the entire feature more feasible, streamlined, and cheap.

Back to the Drawing Board #

We did some thinking (and coding), trying to determine the best way we could provide end users with a great session tracking feature without over-taxing our system in the process, and we were able to come up with a solution!

So, we created a new GET API endpoint /api/v2/events/session/heartbeat (api source) that takes a session id or user id and a flag if the session is closed. This API endpoint then sets a unique session cache key with the current time.

Our existing CloseInactiveSessionsJob.cs was already periodically polling for open sessions to check for inactive sessions so it could automatically close them after a period of time if no session end event was sent, so we just updated this job to check for the unique session cache keys (source) and get the last time a heartbeat was sent in or see if it was closed. It then takes the appropriate action and updates the session event.

Then we just updated the clients to call this new API endpoint when client.Submit.SessionHeartbeat("id") or client.SubmitSessionEnd("id") is called.

Efficiency Achieved! #

Our new solution gives us the ability to have clients send us session heartbeat and session end information very efficiently, which lets us provide a great session tracking feature without adding any additional cost to our plans!

That's how we like to roll, and we hope you find value from the feature and our run down of the process we went through to get it to our users.

Don't Forget to Update Your Client #

If you haven't already updated your client, please do so to start taking advantage of the free session events.

And, as always, please let us know if you've got any feedback or questions. We'd love to hear from you!

New Client Releases Focus on Sessions, Real Time Configuration, and Logging

net-3.5.0-js-1.4.0Exceptionless.NET v3.5.0 and Exceptionless.JavaScript v1.4.0 have been released and they are chock full of new features and feature improvements!

There weren't a whole lot of bug fixes with these releases. Could it be that Exceptionless is working and we've squelched most of the bugs? We think so!

Notably, we focused on sessions, real time configuration, and logging, all of which we think you'll find super helpful.

Read on for details.

Exceptionless .NET Client V3.5.0 and JavaScript Client V1.4.0 Release Notes #

Session Heartbeats No Longer Count Towards Plan Limits! #

We've updated Session Heartbeats and Session End events to be sent through an optimized API end point, and they will no longer count towards your plane's event limits.

Real Time Project Configuration Improvements #

You can now exclude events by type and source, along with setting minimum log levels, in real time. So, for example, if you accidentally disable logging completely, you can simply update your settings and the updates will go into affect, restoring functionality!

UI support will be expanded moving forward, but for the time being here is an example project configuration.



Value: false

Any event type or source can be used, and wildcards * are supported, so you can ignore whole event types and set the source to *.

Disable Submissions of Events with Type Name

Key: @@error:*MyCustomException

**Value: **false

This configuration will disable submission of any error event with a stack trace containing an exception with a type name that ends with MyCustomException. You could also remove the wildcard and specify the full type name with the namespace.

Log Message Settings

Key: @@log:*

Value: off

Even though log types are special cased, they still accept rue or false values, so this example completely turns off log messages.

Other known values are Trace, Debug, Info, Warn, Error, Fatal, and Off.

Minimum Log Level

**Key: **@@log:MyNamespace.EventPostsJob

**Value: **Info

This example is setting the minimum log level for EventPostsJob to Info.

Automatically Check for Updated Configuration Settings on Client Idle #

We've implemented an automatic recurring check for updated configuration settings that occurs two minutes after the last event submission.

A few notes:

  • Each configuration check does not count towards your account's plan limits.
  • No user information will be sent - only the current configuration version.
  • Nothing will be retrieved if no settings have been changed.

The automatic recurring configuration settings check can be disable by calling:


client.Configuration.UpdateSettingsWhenIdleInterval = TimeSpan.Zero;


client.config.updateSettingsWhenIdleInterval = -1;


New Easy Way to Exclude Events from Being Submitted in .NET #

You can now define a simple Func<Event,bool> callback to stop events from being submitted in the .NET client.

For example, if I wanted to ignore any event with a value property of 2 I could use client.Configuration.AddEventExclusion(e => e.Value.GetValueOrDefault() != 2);

Bug Fix for SettingsCollection Boolean Values Support in .NET Client #

SettingsCollection.GetBoolean(name) was not supporting `` or 1 as boolean values, but now it does. We are also now supporting yes and no as valid values.

JavaScript Client Passing Settings Bug #

@csantero fixed an issue with passing settings to a new isntance of ExceptionlessClient - thanks!

Improved Stacking of Angular Response Errors in JavaScript Client #

^^^ Nothing much to say here - the header says it all!

Feedback #

We hope these new features and feature improvements help your Exceptionless experience, and we plan to continue to listen to user feedback and improve the system where improvements need to be made. To do that, though, we need to hear what you want out of the app. If you have a favorite feature request, or something that just bothers you, please let us know by dropping us a line on GitHub Issues under the appropriate repository, listed below, or just comment here and we'll figure it out!

Thanks for reading and have an awesome day!

Exceptionless Keyboard Shortcuts

keyboard-shortcutsToday we've got a quick article on one of the little known features of Exceptionless: keyboard shortcuts.

In an effort to help you navigate Exceptionless event stacks better and troubleshoot faster, we've added keyboard shortcuts that lets you do things like go to the stack from an individual event occurrence, copy the event JSON, navigate to the previous event occurrence, etc.

Let's take a look at all the quick shortcuts you can use to make your Exceptionless usage more efficient.

Bringing Up the Shortcut List #

To bring up the keyboard shortcuts available to each page, simply hold the shift key and hit the forward slash key (SHIFT + /, think ?). This will bring up an overlay showing you which shortcuts are available on that specific page.

Don't see shortcuts available on a page? Don't freak out, there may just not be any. Feel free to suggest something that you think would save yourself and others time, though!

What Shortcuts Exist? #

Event Occurrences #

If you hit SHIFT + / (?) on an event occurrence, you will see three or four new options, depending on whether you are on the first occurrence in the stack or not.

  • **Go to Stack
    ** On any event occurrence, you can hit CTRL + UP to go to that event's stack quicker than finding the "Go To Stack" button and clicking.

  • **Copy Event JSON to Clipboard
    ** Hit CTRL + SHIFT + C to copy that event's JSON data to your clipboard.

  • **Previous Occurrence
    ** CTRL + BACK (LEFT) will take you to the previous event occurrence.

  • **Next Occurrence
    ** And CTRL + FORWARD (RIGHT) will take you to the next occurrence of that event.

Dashboards & Stacks #

On any dashboard or stack, SHIFT + / (?) brings up a simple overlay letting you know that ? will close the overlay and F1 will take you to the Exceptionless documentation on GitHub.

We're open to suggestions for other dashboard or stack shortcuts, just let us know in the comments!

What Shortcuts Would You Use? #

We'd love to get some community input here. What shortcuts do you think would be useful on which Exceptionless pages? Do you have something you do repeatedly on a dashboard or stack page that you think a keyboard shortcut might speed up or make more efficient? Let us know in the comments and we'll do our best to implement your ideas!

Happy coding.

Know How Many Users are Affected by Bugs and Events

exceptionless user trackingPrioritizing your bug fixes and development time in general can be a daunting task.

Sometimes, as developers, we want to work on this shiny widget or this annoying bug, and we don't really have anything in our face telling us to quit focusing on our dreams and work on what matters to the bottom line.

I can hear you over there: "But, my dreams are important!" Well, yes, but you don't get to have fun working on those until you've made your users happy by fixing the bugs that are affecting the majority of them or expanding on that feature that they are all using every single time they use your app.

We've got something that will let you get those pesky tasks off your plate though, so you can move on to the fun stuff!

Who and How Bad Is It? #

Our new "users" column and "Most Users" dashboard lets you know exactly what percentage of your users are being affected by events or using features. This allows you to prioritize the most important bugs or features to work on right away and potentially backlog things that only a few users are having issues with or using.

Of course, you'll need to be sending at least a user id (and preferably a display name) for each user. We'll cover how to do that later in the article.

Percentage of Users Column #

The new Users column on your Exceptionless dashboard displays a percentage value for each event stack that represents the number of users that have been affected by the event or, if it is a feature, that have used the feature.

If you mouse over the percentage, you can see the number of users the percentage represents out of the total.

These numbers are dynamically calculated for your selected timeframe that you are currently viewing.

users affected by bug

Most Users Dashboard #

Because the main dashboard shows you the most frequent events, not necessarily with the highest usage, we thought it would be helpful to have a new dashboard that automatically sorts event stacks by the percentage of users affected, letting you start at the top of an exception list, for example, and work your way down knowing you're always working on a bug, etc, that is affecting the highest percentage of users.

user event dashboard

Setting User Identity #

In order to assure you are getting value out of the user feature, you want to make sure you are setting the user. For Exceptionless to track a user for your app, you need to send a user identity with each event. To do so, you need to set the default user identity via the following client methods:

using Exceptionless;
ExceptionlessClient.Default.Configuration.SetUserIdentity("UNIQUE_ID_OR_EMAIL_ADDRESS", "Display Name");
exceptionless.ExceptionlessClient.default.config.setUserIdentity('UNIQUE_ID_OR_EMAIL_ADDRESS', 'Display Name');

Once the user is set on the config object, it will be applied to all future events.

Please Note: In WinForms and WPF applications, a plugin will automatically set the default user to the **Environment.UserName** if the default user hasn't been already set. Likewise, if you are in a web environment, we will set the default user to the request principal's identity if the default user hasn't already been set.

ASP.NET Example #

You can also manually set the user info on the event directly. This is intended for **multi-user processes (web applications). **For most MVC and WebAPI packages, the user will be set automatically based on the logged in principal, so you don't have to do anything.

// Import the exceptionless namespace.
using Exceptionless;
ExceptionlessClient.Default.CreateFeatureUsage("MyFeature").SetUserIdentity("123456789", "Blake Niemyjski").Submit();

JavaScript Example #

If you're using the JavaScript client, the entire session of the client will typically be for a single user, so you should be able to set it one time when they log in to your app.

exceptionless.ExceptionlessClient.default.setUserIdentity("id", "friendly name")`

Like with .NET, if you are running a multi-user process (Node.js), you'll need to set the user at the event level.

// javascript
var client = exceptionless.ExceptionlessClient.default;

// Node.Js
// var client = require('exceptionless').ExceptionlessClient.default;

client.createFeatureUsage('MyFeature’).setUserIdentity('123456789', 'Blake Niemyjski').submit();

How Will You Use this Data #

We are always interested in how our users use our features, and if our users feature helps our users help their users, well, that's a win win for our users and their users. Go users!

Don't forget to stop by and let us know if you love or hate it, and of course let us know if you think we can improve on anything within Exceptionless.