Warning: This post is over 4 years old and may no longer be accurate, especially in regards to more updated technology currently available. Additionally, links in this post may be broken. Please keep this in mind while reading.
If you have an Umbraco Cloud Account, you have likely noticed a link to “View errors” on some of your environments:
This is a quick way to see how your site is doing, and if there are issues which might need to be addressed.
Clicking through displays all the errors in a list. Click on the small arrow to expand the details.
You can mark individual errors as “read” to hide them from this view, and the environment list’s error count:
Website developers should be aware of this log, and how it works in order to make good decisions about how their code logs errors.
First some technical background… These errors are stored in an additional database table named “UCErrorLog” which is added to Umbraco Cloud websites. There is also an additional LogAppender on Umbraco Cloud sites, that writes to this database table when an error is being logged. This is in addition to whatever other logging is set up on the site writing to the “UmbracoLog” text file (on v7) or to Serilog (on v8).
Development Considerations
As developers, we can be strategic about how we are using logging, and these Portal-visible errors adds an additional dimension to logging strategies.
An individual log item has to have a type of “Error” to be included in the database table – and thus on the Portal errors screen, so when choosing to log some part of your code as an “Error” be aware that it will end up in the database and visible in the Portal.
There are two things to consider when deciding if you want to log a “caught” exception as an error or not.
- Database bloat – If you have a piece of code which catches a lot of exceptions of a non-critical nature, make a conscious choice about whether they deserve database space or not.
- Visibility – Being listed in the Cloud Portal means that you, as a developer, and possibly other website Users (who have Portal access) will more likely become aware of the error. You might not want non-critical “handled” errors to be added to that count of errors visible to everyone (including your client?). Alternately, you may want certain types of “issues” (even if handled to avoid ugly front-end YSODs) to be surfaced there for more immediate investigation and specific resolution (for instance, NULL exceptions related to missing Content, etc.)
With these things in mind you can be intentional about what you decide to log as an “Error”. I suggest considering the “Warn” type for items which you might want to be visible with deeper investigation, but that shouldn’t be visible in the Cloud Portal.
Environment-Specific Logging
You might also consider ways to alter your logging of a specific item based on the environment the code is running on. For instance, I have some code which relies on having HTTP access to pages of the site. Due to the basic authentication in place on Umbraco Cloud development and staging environments, this code ALWAYS fails with an “access denied” error when running on those environments. I don’t need all those failures logged on development and staging, since they aren’t actually anything I need to “fix”, but if that code failed on Live, I WOULD want to know, since it really SHOULD work fine there. My solution is to use an environment-specific web.config value to determine the logging type.
Umbraco Cloud sites utilize environment-specific web.config transforms, so this is an easy thing to put in place.
In my web.config:
<appSettings>
…
<add key="CurrentEnvironment" value="Local"/>
…
</appSettings>
In the “Web.Development.xdt.config” file:
<appSettings>
<add key="CurrentEnvironment" value="Development" xdt:Transform="SetAttributes(value)" xdt:Locator="Match(key)" />
</appSettings>
In the “Web.Live.xdt.config” file:
<appSettings>
<add key="CurrentEnvironment" value="Live" xdt:Transform="SetAttributes(value)" xdt:Locator="Match(key)" />
</appSettings>
Now a check of the "CurrentEnvironment" value tells me what environment the code is running in and can log accordingly.
Using the Portal Errors for Maintenance
If you are actively maintaining the site, periodically review the Errors in the Portal for recurring problems and un-handled exceptions. Some code fixes – or at least more extensive error-handling – can help your site stay spic-and-span.
Occasional Database Cleanup
If your site is logging a lot of errors and you don’t need to keep them, you can run an SQL query on the various environment-specific databases in order to clear out the table, based on how much you want to keep.
I had an issue with an inherited site which had been neglected for some time. The number of errors logged for the live environment was over 200,000. I wasn’t even able to view those errors in the Portal errors screen because there were too many to load. This script cleared out the bulk of those old un-read errors and I was able to see the most recent batch in the Portal:
DELETE TOP(90) PERCENT
FROM [dbo].[UCErrorLog]
WHERE [Read] = 0
Awareness and active management of the Umbraco Cloud Portal errors can improve your website’s operation – and your developer reputation.
* Special thanks to Dennis at Umbraco Cloud support for providing information about the UCErrorLog table and the SQL to clean it up.
