Problem Details (RFC 7807) support in Uptime Monitoring

Uptime Monitoring now supports Problem Details in the response from your endpoints. You may not know about Problem Details, but it's a standard for returning detailed error messages from web APIs. Problem Details are supported by most web frameworks already and we recommend you to adopt the standard, rather than inventing new response formats for communicating errors back from your API.

If our Uptime checker identifies Problem Details in your response, we extract this information and present it as part of the logged error.

Check out the specification here:

Blogged: Tuning performance on Azure websites using remote profiling

Data Processing Agreement

Under the new rules set by EU GDPR, we should be able to sign a Data Processing Agreement (DPA) with our customers. I'm happy to report, that our DPA is now ready. If you want to sign a DPA between and your company, please reach out to our support.

Sort by groups

Sorting on grouping keys is now available by clicking the new Group header:

Sort by group

Sorting by group can be used for a range of scenarios, like seeing which URL causes most errors. To do so, choose URL in the Group by dropdown and sort descending by clicking the Group table header.

Message limit timespan and notifications

As I've mentioned 100 times already (will keep mentioning it), May 1st marks the day where we will start enforcing message limits. We are currently playing around with a bunch of things, in order to make the transition as smooth as possible. One of the things I've heard from multiple of you, is a bit of annoyance regarding the message limit exceeded email. You want it when it happens and not every freaking day :) So, today we've changed that. You will get a warning when you reach 90% consumption of either messages or emails. And you will receive a new email when going over the message or email limits.

When implementing this change, we realized that using rolling 30 days simply wasn't good enough. Our checks were based on an algorithm, looking through the last 30 days of usage. With this approach, it's simply not possible to send a single email, when you go over the limit (since you could do that daily). In order to fix that, and to make the new limit even easier to understand, we've changed the timespan to follow calendar months.

This means that we will reset the counter first day of the month and you will have the included number of messages available during that month. If you reach your limit, let's say the 28th, you will receive an email. It's up to you if you want to live without logging the following 2-3 days or if you want to upgrade. We think that's a fair, transparent and easy to understand solution for everyone.

Let us know if you have any questions, ok?

Introducing profile photos (bye bye Gravatar)

As part of our efforts towards GDPR compliance, we are looking through external services that we share data with. One of these is Gravatar, which we have been using from day one. Gravatar is a simple service, returning either a profile picture (if the user has a Gravatar account) or a default user icon. While this is a neat feature, we need to share your hashed email address with Gravatar. This means that they in theory can track your webpage usage. We want to limit the amount of services able to do so and since a profile photo can be implemented on instead, we have decided to do that.

On the Profile view, there's a new Profile photo section:

Profile Photo

When choosing a file and uploading the photo, your teammates are able to see your new photo.

Contains filter

We just extended Search Filters with a new feature. It is now possible to search using Contains:

Contains Filter

Play around with it and please get back to us with feedback. It is still based on Elasticsearch full-text queries, why the behavior doesn't necessarily match an IndexOf or SQL LIKE statement.

Using from AWS Lambdas

AWS now supports .NET Core, why works out of the box on Amazon's cloud too. We have started to write some documentation on how to log to from AWS Lambdas.

Supporting NLog 4.5 and structured logging

NLog 4.5 were published a little over a week ago and we want to show our support with a compatible version too. As of today, our integration (Elmah.Io.NLog) runs on NLog 4.5 and also supports the new structured logging feature available in 4.5.

More info on the blog: Supporting NLog 4.5 and structured logging

GDPR changes

We are actively working with GDPR compliance, which will result in a series of minor adjustments to the UI and new features. We won't inform you about every little change, but here's an overview of recent changes.

When signing up, you will now be prompted to accept both terms and privacy policy:


We are currently building a system where we are able to collect acceptance from those of you who haven't accepted terms in a way approved by GDPR, as well as a way for us to notify you when we update our terms. Expect an email within the next month or so.

On the profile, there's a new toggle to restrict processing:

Restrict processing

In plain English this toggle removes access from our employees to your personal data (name, email, etc.). We never misuse your data or sell it to third-party and having access helps us in the case we need to support you. But according to GDPR, you should be in charge :)

Expect more changes soon. You can follow our work against GDPR compliance on our GDPR wiki.

No published changelogs yet.

Surely elmah-io will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree