Why Use Errsole

Error Logging

Conventional Error Reporting and Resolution

When a customer encounters an error while using a web app, he reports it to the support team. Then, a support team member reaches out to the customer to gather specifics on how to reproduce the error. Afterward, this support team member creates a ticket and assigns it to a developer.

The developer begins troubleshooting by adding log statements into the code and deploying the app. By following the instructions provided by the customer, the developer reproduces the error. He then examines the logs to find the root cause and proceeds to fix the error.

Problems with Conventional Error Reporting

• The developer doesn’t initiate troubleshooting until a customer reports the error. How often do customers bother to report errors?
• Even if a customer does report the error, how many days does the troubleshooting process take?
• In the meantime, how many customers would be affected by this error?

For startups, in particular, customers often opt to stop using the product rather than reporting errors.

Error Logging with Errsole

Errsole captures all the information you need to reproduce an error.

All popular web frameworks are stateless. They follow a simple process: receive an HTTP request, process it, and send back a response. So, in web applications, when an error occurs, it is typically triggered by an HTTP request.

When a customer encounters an error in your app, Errsole captures both the error and the corresponding HTTP request made by the customer. This information is all you need to reproduce the error. You can reproduce and troubleshoot the error anytime just by replaying the request. There is no need to rely on the customer to reproduce the error or to insert log statements into your code and wait for the error to occur again.

Error Reproduction

If you can’t reproduce the error, you can’t resolve the error.

Conventional Error Reproduction

It takes hours, days, or even weeks to reproduce a customer-reported error.

How do developers respond when a customer reports an error? First, they reach out to the customer to gather information about the steps needed to reproduce the error. Then, they insert log statements into the code and deploy the app. Following that, they attempt to recreate the error by following the instructions provided by the customer.

Alternatively, they insert log statements into the code, deploy the app, and then wait for the error to occur again.

This process might extend over hours, days, or even weeks. In the meantime, the same error affects other customers.

The error successfully ruins the product’s reputation before it is resolved.

Error Reproduction with Errsole

With Errsole, you can reproduce a customer error with just a click of a button.

When a customer encounters an error in your app, Errsole automatically captures both the error and the corresponding HTTP request made by the customer.

When a developer opens the Errsole Debugger in his browser, Errsole starts a dedicated sandbox app on your server for the developer. This sandbox app is a clone of the live app, but it does not receive any user traffic. This separation guarantees that the troubleshooting does not impact the actual users of the app.

Following that, a secure and direct connection is established between the developer’s browser and the sandbox app.

Within the Errsole Debugger, the developer can replay the original customer request with a simple button click. This replay occurs within the sandbox app, which mirrors the live app. This action effectively reproduces the customer’s error within the sandbox app while the actual users of the app remain unaffected.

Using the Errsole Debugger, you can reproduce the customer errors with just a click of a button and debug the server code, all without disturbing the real app users.

Remote Debugging

Conventional Debugger

Troubleshooting errors during development is easy, thanks to the debugger. Nowadays, most IDEs come with a built-in debugger.

When an error occurs during development, first, the developer sets breakpoints in the code using the debugger. These breakpoints act as designated stopping points. Next, the developer reproduces the error by replicating the exact sequence of actions that led to the error. At the breakpoints, the debugger intervenes and temporarily halts the code execution. This interruption provides an opportunity for the developer to examine the values of variables at precise locations within the code. This in-depth examination helps the developer understand the root cause of the error.

Problems with the Conventional Debugger

Though the debugger is the most powerful tool to troubleshoot errors, there are several challenges in using a debugger in the production environment.

Debugger Halts the App

When a debugger halts the code execution, it halts the entire app process. As a result, no one can use the app. This works during development since the developer is the sole user of the app. However, in the production environment, the app will be inaccessible to all users.

Security Risks

During development, the debugger operates on the local system and is not accessible via the Internet. It can only be accessed by the developer using the local system, ensuring no security risks. In contrast, a remote debugger is accessible over the Internet. This accessibility introduces potential threats. If an unauthorized person gains access to the debugger, he could compromise the entire app.

Errsole Debugger: Non-blocking and Secure

With Errsole Debugger, you can fix production errors in minutes.

Errsole Debugger is a remote debugging tool for the production environment. Using Errsole Debugger, you can set breakpoints, reproduce errors, inspect variables, and verify the fixes within your production environment.

Errsole Debugger Is Non-blocking

A developer can sign in to Errsole using his preferred web browser. If the developer has the necessary permissions, he can view all errors that have occurred in your app. He can then choose a specific error for troubleshooting. This action directs the developer to the Errsole Debugger page.

Upon loading the Errsole Debugger, Errsole starts a dedicated sandbox app on your server for the developer. This sandbox app is a clone of the live app. Following that, a secure and direct connection is established between the developer’s browser and the sandbox app.

The sandbox app is only connected to the Errsole Debugger loaded in the developer’s browser. It does not receive any user traffic. This separation guarantees that the troubleshooting does not impact the actual users of the app.

After the developer completes the debugging and closes the browser, the sandbox app associated with that browser will be automatically terminated.

Errsole Is Secure

Errsole does not access your code. It only collects and stores errors that occur in your app, alongside additional details related to the errors, like HTTP requests.

Errsole provides a three-layer security for your app. This effectively safeguards your app against any unauthorized access.

Errsole Debugger offers the advantages of a debugger for your production environment minus the associated risks. With Errsole Debugger, you can fix production errors in minutes rather than spending hours, days, or even weeks.

Collaboration

On the Errsole website, you and fellow admins can invite developers to join your app team. Within this team, you can set permissions for each developer. Errsole then enforces these permissions on developers. Additionally, you can assign errors to individual developers.

Concurrent Debugging

Whenever a developer accesses the Errsole Debugger in his browser, Errsole starts a dedicated sandbox app on your server for the developer. This sandbox app is a clone of the live app. Following that, a secure and direct connection is established between the developer’s browser and the sandbox app.

After the developer completes the debugging and closes the browser, the sandbox app associated with that browser will be automatically terminated.

With this setup, developers can concurrently troubleshoot the specific errors assigned to them within their sandbox apps without affecting other developers or app users.

3 Layers of Security

Errsole implements a three-layer security approach to safeguard your app.

Layer 1: App-level Permissions

When setting up the Errsole module in your app, you can set permissions in the module configuration. These permissions can not be modified or circumvented by anything external to your server, including Errsole itself.

Layer 2: Developer Permissions

On the Errsole website, you and fellow admins can set permissions for each developer in your app team. Errsole then enforces these permissions on developers.

It is important to note that permissions set in the Errsole module configuration take precedence. In other words, if a permission is denied in the Errsole module configuration, it is denied universally. It is not possible to grant that specific permission to any developer via the Errsole website.

Layer 3: 2-factor Authentication

Errsole supports 2-factor authentication, which adds an extra layer of protection to your developer accounts.