- Developer Hub
- Email Tools
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- Deliverability Guide
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Contact Us
Mistakes happen. It’s a fact of life. But, mistakes are often a precursor to growth…as long as you learn from them!
Early on after launching our service, the SparkPost support team occasionally received feedback from customers who tried to sign up for one of our paid tiers, explaining that the transaction failed. Not only did that stink for our customers, but it was a real pain point for us as well. We knew that sort of error couldn’t continue unchecked, so we decided to get to the bottom of this frustrating problem.
We integrate with a third party for payment processing, and the third-party system sometimes responds to a request with what’s essentially an unknown error. Super helpful! In most cases, we were able to surface a more helpful error to the user based on logic that parses the response. But up until a few months ago, we had zero visibility into the unknown errors. We had no way to help our customers, and no way to learn from the problem! After looking at a few more third-party solutions, we decided to leverage functionality our current stack already provided.
From the Nginx side, we’re able to customize our log format by leveraging the built in directives and variables available in the core module as well as the log and proxy modules. In our case, we’re using the
log_formatdirectives, and the
$msecvariable from the log module. Then
$proxy_add_x_forwarded_forfrom the proxy module. We get
$request_bodyfrom the core module. With that in place, we can easily see information about the request, in addition to the data being sent from the UI.1log_format uierr '$msec "$proxy_add_x_forwarded_for" $http_user_agent "$request_body"';
Finally, back to our front-end code and the case of uncaught exceptions. Angular comes with a global application exception handler
$exceptionHandlerthat does exactly that. In our case, we use the
$decoratormethod to add additional behavior. It’s called in the config phase callback, so that the decorator can intercept the service creation, and we use the
Now, whenever our support team needs to assist customers with their subscriptions, we’re able to quickly access additional details, and as an added bonus, we have an easy way to gain insight into exceptions within our application to prevent future occurrences! Learning from this previously frustrating error turned out to be an opportunity for improving the customer experience—and for making the internals of our application better, as well.SparkPost © 2017 All Rights Reserved