×
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
6 minutes read
Debugging Microservice Applications with Thundra
Written by Ismail Egilmez
Business Development Manager @Thundra


![]()
1. TTD (Time Travel Debugging)
Debugging has traditionally been done during the development of software by putting breakpoints to the suspicious lines of the code. And when the execution hits the breakpoint, it stops naturally and you get the outputs you need in order to understand the root cause of a defect.
What if your software is a modern application, actively running in production and serving users. In this case, you are mostly left alone with logs. You have to be very organized and try to debug the application on your assumptions. This requires a ton of manual work and still pollutes the code.
Thundra’s TTD feature enables you to debug any application (serverless, containerized, etc.) and your tests without any hassle.

TTD (TimeTravel Debugging) makes it possible to travel back in time to previous states of your application by getting a snapshot of when each line is executed.
Clicking on one of the spans on the above trace chart will start your TTD experience.

You can step over each line of the code and track the values of the variables at each application execution or test run. You can navigate through the lines of the code of your application or test run and see the changes in the variables.
How it works:
You can enable TTD by simply configuring Thundra’s Node.js, Python, and Java agents with the environment variables without any code change.
If you want to debug your test runs, TTD can be enabled for Maven and Gradle tests as in this documentation.
Benefits:
- Save time without manual work.
- Save cost, no need for additional logging.
- No guesswork of where to place breakpoints.
- Debug apps and tests without stopping them.
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.js: 2.8.0, layer 36 or higher
- Python: 2.4.4, layer 19 or higher
- Java: 2.4.9, layer 39 or higher
- Node.JS (by VSCode plugin)
- Python (by VSCode plugin)
- Java (by IntelliJ IDEA plugin)
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
- Thundra APM
- Thundra Foresight
- Thundra APM
- Thundra APM
Use Cases:
- Serverless debugging
- Test debugging
- Production debugging
- Pre-production debugging
- Production debugging
- Pre-production debugging
2.LSD (Live Serverless Debugging)
Debugging means replaying the execution of an application in some means. Where in serverless applications, more specifically in AWS Lambda applications, replaying the same exact invocation is not always possible due to the black-box nature of it.
Traditionally, it is not possible to put breakpoints in a Lambda function, stop the execution and debug as usual.
Debugging serverless applications locally may make sense in some situations. But it is clear that mocking the cloud environment and debugging serverless applications locally misses some crucial points such as security permissions and authenticity of event data flowing between resources.
Thundra’s “AWS Lambda Debugger” makes it possible to put breakpoints in your IDE to your Lambda functions and debug them just like in your local environment.
How it works:
Thundra’s AWS Lambda Debugger sets up a secure bridge between the AWS Lambda environment and your debugger on your IDE via a web socket communication. This allows you to debug your Lambda’s, enabling you to see the values of local variables and the entire stack trace.

As in the above image, Thundra’s AWS Lambda Debugger sets up a secure bridge to exchange data between the AWS Lambda environment and the IDE. The bridge encrypts the data while exchanging it between several nodes.
2.1. VSCode Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your VSCode IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the VSCode marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the settings page.
- Open the Command Palette (⇧⌘P) and select the Thundra: Edit Configuration command to modify the configuration file.
How to use:
- Set a debugging point on your AWS Lambda function.
Execute the command Thundra: Start Debugger to start the debugging session. (Alternatively, you can click on the Start Thundra Debugger button on the Status Bar.)
- Now invoke your AWS Lambda function to hit on the debugging point.
- The debugging session ends when your AWS Lambda function times out. You can update the timeout of your function for longer sessions.
.gif)
2.2. IntelliJ IDEA Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your IntelliJ IDEA IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the Settings page. Learn how to get your authentication key.
- Click on “Run – Edit Configurations” and then click the “Add” button to create a new configuration.
- Select “Thundra Debugger” for the new configuration.
- Set your authentication key to the variable “Authentication Token” on the configuration modal. Enter a name for this new profile and then save.
How to use:
- Set a debugging point on your AWS Lambda function.
- Select a profile from the Run Configurations drop-down menu.
- Click on the “Debug” button to start a debugging session with the selected profile.
- Now invoke your AWS Lambda function to hit on the debugging point.
- The session ends when your AWS Lambda function times out. You can change the timeout value of your function to perform longer debugging sessions.
-1.gif?width=641&name=thundra-intellij%20(1)-1.gif)
2.3. Self-Hosted Broker
Organizations with security concerns choose the self-hosted version of Thundra’s AWS Lambda Debugger because their data does not leave their own cloud (AWS) account.
A self-hosted instance of the broker that provides the necessary functionality for online debugging can be installed on your own AWS account using our CloudFormation template or you can perform a manual installation using the Docker image we provide.

The self-hosted broker can be configured with different access settings as in the image above:
- Broker with only internal access
- Broker with public access
- Broker with internal and public access
Benefits:
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
Support:
Thundra Products:
Use Cases:
- Serverless debugging
- Pre-production debugging
3. NIRD (Non-Intrusive Remote Debugging)
Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application.
How it works:
- Instrument your applications
You need to install Thundra Sidekick in your application in order to gather information during the execution of your application. Here’s the quick installation guide.
Thundra Sidekick integrates with GitHub and GitLab to retrieve your code in any branch or any commit. When you provide access to your GitHub or GitLab repository, Sidekick retrieves the code with read-only access and keeps it in your client application.
Your source code is never brought onto our servers, ensuring your privacy remains intact.

Tracepoint is a non-breaking breakpoint integrated with Thundra’s distributed technology. We call it tracepoints instead of breakpoints as we integrate them with our distributed tracing technology.

Thundra Sidekick takes a snapshot of the variables and the call stack when the code execution hits the tracepoint. The code does not pause in the breakpoint. All valuable data is retrieved with negligible(less than 1ms) performance overhead.

- Connect Dots with distributed tracing
Thundra Sidekick connects several tracepoints in the same distributed transaction. Developers can navigate between the snapshots of the same transaction and achieve end-to-end visibility for debugging.

Thundra Sidekick will allow you to reload the code in remote environments without re-deploying your applications.
You can use Sidekick in two ways. By its Cloud debugger which is basically a web application and its IntelliJ IDEA plugin directly from your IDE. Here’s a quick start guide for Python and Java applications.
In this video, we are debugging the Pet Clinic App by Spring to demonstrate Thundra Sidekick’s capabilities.
3.1. Cloud Debugger (Web Application)
Thundra Sidekick’s cloud debugger connects to your code repository and lets you import any project you wish. Code import is as easy as just a few clicks. The integration works for GitHub, GitLab, Bitbucket, and more.
Get started from here.

3.2. IntelliJ IDEA Plugin
Thundra Sidekick’s IntelliJ IDEA IDE plugin enables you to debug your microservices without leaving your IDE. You can set tracepoints to your code from the comfort of your IDE. It just feels like debugging your remote apps in your local environment.
Get started from here.

Benefits:
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
Use Cases:
- Production debugging
- Pre-production debugging
Conclusion
If you already have a Thundra account you can get started benefiting from the mentioned debugging capabilities by just using the appropriate Thundra product.
Please refer to the relevant product documentation for more information. If you have any questions and want to learn more about Thundra products, you can contact us at [email protected], join our community slack channel , connect with us on Twitter and LinkedIn.
And if you have yet to take your first step into the world of Thundra, you can begin your journey here.

![]()
1. TTD (Time Travel Debugging)
Debugging has traditionally been done during the development of software by putting breakpoints to the suspicious lines of the code. And when the execution hits the breakpoint, it stops naturally and you get the outputs you need in order to understand the root cause of a defect.
What if your software is a modern application, actively running in production and serving users. In this case, you are mostly left alone with logs. You have to be very organized and try to debug the application on your assumptions. This requires a ton of manual work and still pollutes the code.
Thundra’s TTD feature enables you to debug any application (serverless, containerized, etc.) and your tests without any hassle.

TTD (TimeTravel Debugging) makes it possible to travel back in time to previous states of your application by getting a snapshot of when each line is executed.
Clicking on one of the spans on the above trace chart will start your TTD experience.

You can step over each line of the code and track the values of the variables at each application execution or test run. You can navigate through the lines of the code of your application or test run and see the changes in the variables.
How it works:
You can enable TTD by simply configuring Thundra’s Node.js, Python, and Java agents with the environment variables without any code change.
If you want to debug your test runs, TTD can be enabled for Maven and Gradle tests as in this documentation.
Benefits:
- Save time without manual work.
- Save cost, no need for additional logging.
- No guesswork of where to place breakpoints.
- Debug apps and tests without stopping them.
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.js: 2.8.0, layer 36 or higher
- Python: 2.4.4, layer 19 or higher
- Java: 2.4.9, layer 39 or higher
- Node.JS (by VSCode plugin)
- Python (by VSCode plugin)
- Java (by IntelliJ IDEA plugin)
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
- Thundra APM
- Thundra Foresight
- Thundra APM
- Thundra APM
Use Cases:
- Serverless debugging
- Test debugging
- Production debugging
- Pre-production debugging
- Production debugging
- Pre-production debugging
2.LSD (Live Serverless Debugging)
Debugging means replaying the execution of an application in some means. Where in serverless applications, more specifically in AWS Lambda applications, replaying the same exact invocation is not always possible due to the black-box nature of it.
Traditionally, it is not possible to put breakpoints in a Lambda function, stop the execution and debug as usual.
Debugging serverless applications locally may make sense in some situations. But it is clear that mocking the cloud environment and debugging serverless applications locally misses some crucial points such as security permissions and authenticity of event data flowing between resources.
Thundra’s “AWS Lambda Debugger” makes it possible to put breakpoints in your IDE to your Lambda functions and debug them just like in your local environment.
How it works:
Thundra’s AWS Lambda Debugger sets up a secure bridge between the AWS Lambda environment and your debugger on your IDE via a web socket communication. This allows you to debug your Lambda’s, enabling you to see the values of local variables and the entire stack trace.

As in the above image, Thundra’s AWS Lambda Debugger sets up a secure bridge to exchange data between the AWS Lambda environment and the IDE. The bridge encrypts the data while exchanging it between several nodes.
2.1. VSCode Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your VSCode IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the VSCode marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the settings page.
- Open the Command Palette (⇧⌘P) and select the Thundra: Edit Configuration command to modify the configuration file.
How to use:
- Set a debugging point on your AWS Lambda function.
Execute the command Thundra: Start Debugger to start the debugging session. (Alternatively, you can click on the Start Thundra Debugger button on the Status Bar.)
- Now invoke your AWS Lambda function to hit on the debugging point.
- The debugging session ends when your AWS Lambda function times out. You can update the timeout of your function for longer sessions.
.gif)
2.2. IntelliJ IDEA Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your IntelliJ IDEA IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the Settings page. Learn how to get your authentication key.
- Click on “Run – Edit Configurations” and then click the “Add” button to create a new configuration.
- Select “Thundra Debugger” for the new configuration.
- Set your authentication key to the variable “Authentication Token” on the configuration modal. Enter a name for this new profile and then save.
How to use:
- Set a debugging point on your AWS Lambda function.
- Select a profile from the Run Configurations drop-down menu.
- Click on the “Debug” button to start a debugging session with the selected profile.
- Now invoke your AWS Lambda function to hit on the debugging point.
- The session ends when your AWS Lambda function times out. You can change the timeout value of your function to perform longer debugging sessions.
-1.gif?width=641&name=thundra-intellij%20(1)-1.gif)
2.3. Self-Hosted Broker
Organizations with security concerns choose the self-hosted version of Thundra’s AWS Lambda Debugger because their data does not leave their own cloud (AWS) account.
A self-hosted instance of the broker that provides the necessary functionality for online debugging can be installed on your own AWS account using our CloudFormation template or you can perform a manual installation using the Docker image we provide.

The self-hosted broker can be configured with different access settings as in the image above:
- Broker with only internal access
- Broker with public access
- Broker with internal and public access
Benefits:
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
Support:
Thundra Products:
Use Cases:
- Serverless debugging
- Pre-production debugging
3. NIRD (Non-Intrusive Remote Debugging)
Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application.
How it works:
- Instrument your applications
You need to install Thundra Sidekick in your application in order to gather information during the execution of your application. Here’s the quick installation guide.
Thundra Sidekick integrates with GitHub and GitLab to retrieve your code in any branch or any commit. When you provide access to your GitHub or GitLab repository, Sidekick retrieves the code with read-only access and keeps it in your client application.
Your source code is never brought onto our servers, ensuring your privacy remains intact.

Tracepoint is a non-breaking breakpoint integrated with Thundra’s distributed technology. We call it tracepoints instead of breakpoints as we integrate them with our distributed tracing technology.

Thundra Sidekick takes a snapshot of the variables and the call stack when the code execution hits the tracepoint. The code does not pause in the breakpoint. All valuable data is retrieved with negligible(less than 1ms) performance overhead.

- Connect Dots with distributed tracing
Thundra Sidekick connects several tracepoints in the same distributed transaction. Developers can navigate between the snapshots of the same transaction and achieve end-to-end visibility for debugging.

Thundra Sidekick will allow you to reload the code in remote environments without re-deploying your applications.
You can use Sidekick in two ways. By its Cloud debugger which is basically a web application and its IntelliJ IDEA plugin directly from your IDE. Here’s a quick start guide for Python and Java applications.
In this video, we are debugging the Pet Clinic App by Spring to demonstrate Thundra Sidekick’s capabilities.
3.1. Cloud Debugger (Web Application)
Thundra Sidekick’s cloud debugger connects to your code repository and lets you import any project you wish. Code import is as easy as just a few clicks. The integration works for GitHub, GitLab, Bitbucket, and more.
Get started from here.

3.2. IntelliJ IDEA Plugin
Thundra Sidekick’s IntelliJ IDEA IDE plugin enables you to debug your microservices without leaving your IDE. You can set tracepoints to your code from the comfort of your IDE. It just feels like debugging your remote apps in your local environment.
Get started from here.

Benefits:
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
Use Cases:
- Production debugging
- Pre-production debugging
Conclusion
If you already have a Thundra account you can get started benefiting from the mentioned debugging capabilities by just using the appropriate Thundra product.
Please refer to the relevant product documentation for more information. If you have any questions and want to learn more about Thundra products, you can contact us at [email protected], join our community slack channel , connect with us on Twitter and LinkedIn.
And if you have yet to take your first step into the world of Thundra, you can begin your journey here.

![]()
1. TTD (Time Travel Debugging)
Debugging has traditionally been done during the development of software by putting breakpoints to the suspicious lines of the code. And when the execution hits the breakpoint, it stops naturally and you get the outputs you need in order to understand the root cause of a defect.
What if your software is a modern application, actively running in production and serving users. In this case, you are mostly left alone with logs. You have to be very organized and try to debug the application on your assumptions. This requires a ton of manual work and still pollutes the code.
Thundra’s TTD feature enables you to debug any application (serverless, containerized, etc.) and your tests without any hassle.

TTD (TimeTravel Debugging) makes it possible to travel back in time to previous states of your application by getting a snapshot of when each line is executed.
Clicking on one of the spans on the above trace chart will start your TTD experience.

You can step over each line of the code and track the values of the variables at each application execution or test run. You can navigate through the lines of the code of your application or test run and see the changes in the variables.
How it works:
You can enable TTD by simply configuring Thundra’s Node.js, Python, and Java agents with the environment variables without any code change.
If you want to debug your test runs, TTD can be enabled for Maven and Gradle tests as in this documentation.
Benefits:
- Save time without manual work.
- Save cost, no need for additional logging.
- No guesswork of where to place breakpoints.
- Debug apps and tests without stopping them.
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.js: 2.8.0, layer 36 or higher
- Python: 2.4.4, layer 19 or higher
- Java: 2.4.9, layer 39 or higher
- Node.JS (by VSCode plugin)
- Python (by VSCode plugin)
- Java (by IntelliJ IDEA plugin)
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
- Thundra APM
- Thundra Foresight
- Thundra APM
- Thundra APM
Use Cases:
- Serverless debugging
- Test debugging
- Production debugging
- Pre-production debugging
- Production debugging
- Pre-production debugging
2.LSD (Live Serverless Debugging)
Debugging means replaying the execution of an application in some means. Where in serverless applications, more specifically in AWS Lambda applications, replaying the same exact invocation is not always possible due to the black-box nature of it.
Traditionally, it is not possible to put breakpoints in a Lambda function, stop the execution and debug as usual.
Debugging serverless applications locally may make sense in some situations. But it is clear that mocking the cloud environment and debugging serverless applications locally misses some crucial points such as security permissions and authenticity of event data flowing between resources.
Thundra’s “AWS Lambda Debugger” makes it possible to put breakpoints in your IDE to your Lambda functions and debug them just like in your local environment.
How it works:
Thundra’s AWS Lambda Debugger sets up a secure bridge between the AWS Lambda environment and your debugger on your IDE via a web socket communication. This allows you to debug your Lambda’s, enabling you to see the values of local variables and the entire stack trace.

As in the above image, Thundra’s AWS Lambda Debugger sets up a secure bridge to exchange data between the AWS Lambda environment and the IDE. The bridge encrypts the data while exchanging it between several nodes.
2.1. VSCode Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your VSCode IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the VSCode marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the settings page.
- Open the Command Palette (⇧⌘P) and select the Thundra: Edit Configuration command to modify the configuration file.
How to use:
- Set a debugging point on your AWS Lambda function.
Execute the command Thundra: Start Debugger to start the debugging session. (Alternatively, you can click on the Start Thundra Debugger button on the Status Bar.)
- Now invoke your AWS Lambda function to hit on the debugging point.
- The debugging session ends when your AWS Lambda function times out. You can update the timeout of your function for longer sessions.
.gif)
2.2. IntelliJ IDEA Plugin
It is pretty easy to get started using Thundra’s AWS Lambda Debugger on your IntelliJ IDEA IDE.
Here are the simple steps to follow for installation.
Installation:
- Install the extension from the marketplace.
- Sign up for Thundra and select the Thundra Debugger option to receive your authentication key. If you’ve already signed up, you can get your key from the Settings page. Learn how to get your authentication key.
- Click on “Run – Edit Configurations” and then click the “Add” button to create a new configuration.
- Select “Thundra Debugger” for the new configuration.
- Set your authentication key to the variable “Authentication Token” on the configuration modal. Enter a name for this new profile and then save.
How to use:
- Set a debugging point on your AWS Lambda function.
- Select a profile from the Run Configurations drop-down menu.
- Click on the “Debug” button to start a debugging session with the selected profile.
- Now invoke your AWS Lambda function to hit on the debugging point.
- The session ends when your AWS Lambda function times out. You can change the timeout value of your function to perform longer debugging sessions.
-1.gif?width=641&name=thundra-intellij%20(1)-1.gif)
2.3. Self-Hosted Broker
Organizations with security concerns choose the self-hosted version of Thundra’s AWS Lambda Debugger because their data does not leave their own cloud (AWS) account.
A self-hosted instance of the broker that provides the necessary functionality for online debugging can be installed on your own AWS account using our CloudFormation template or you can perform a manual installation using the Docker image we provide.

The self-hosted broker can be configured with different access settings as in the image above:
- Broker with only internal access
- Broker with public access
- Broker with internal and public access
Benefits:
- 100% secure, your data does not leave your own AWS account.
- No local issue reproduction, debug Lambda applications during the invocation execution.
- Do not stop the whole process, just debug/stop 1 Lambda invocation at a time.
Support:
Thundra Products:
Use Cases:
- Serverless debugging
- Pre-production debugging
3. NIRD (Non-Intrusive Remote Debugging)
Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application.
How it works:
- Instrument your applications
You need to install Thundra Sidekick in your application in order to gather information during the execution of your application. Here’s the quick installation guide.
Thundra Sidekick integrates with GitHub and GitLab to retrieve your code in any branch or any commit. When you provide access to your GitHub or GitLab repository, Sidekick retrieves the code with read-only access and keeps it in your client application.
Your source code is never brought onto our servers, ensuring your privacy remains intact.

Tracepoint is a non-breaking breakpoint integrated with Thundra’s distributed technology. We call it tracepoints instead of breakpoints as we integrate them with our distributed tracing technology.

Thundra Sidekick takes a snapshot of the variables and the call stack when the code execution hits the tracepoint. The code does not pause in the breakpoint. All valuable data is retrieved with negligible(less than 1ms) performance overhead.

- Connect Dots with distributed tracing
Thundra Sidekick connects several tracepoints in the same distributed transaction. Developers can navigate between the snapshots of the same transaction and achieve end-to-end visibility for debugging.

Thundra Sidekick will allow you to reload the code in remote environments without re-deploying your applications.
You can use Sidekick in two ways. By its Cloud debugger which is basically a web application and its IntelliJ IDEA plugin directly from your IDE. Here’s a quick start guide for Python and Java applications.
In this video, we are debugging the Pet Clinic App by Spring to demonstrate Thundra Sidekick’s capabilities.
3.1. Cloud Debugger (Web Application)
Thundra Sidekick’s cloud debugger connects to your code repository and lets you import any project you wish. Code import is as easy as just a few clicks. The integration works for GitHub, GitLab, Bitbucket, and more.
Get started from here.

3.2. IntelliJ IDEA Plugin
Thundra Sidekick’s IntelliJ IDEA IDE plugin enables you to debug your microservices without leaving your IDE. You can set tracepoints to your code from the comfort of your IDE. It just feels like debugging your remote apps in your local environment.
Get started from here.

Benefits:
- No additional code, no code pollution.
- No need for reproducing issues locally.
- Debug apps without stopping them.
- Debug live production environment.
- Detect errors at a glance by distributed tracing.
Support:
- Node.JS (coming soon)
- Python (by cloud debugger)
- Java (by IntelliJ IDEA plugin)
Thundra Products:
Use Cases:
- Production debugging
- Pre-production debugging
Conclusion
If you already have a Thundra account you can get started benefiting from the mentioned debugging capabilities by just using the appropriate Thundra product.
Please refer to the relevant product documentation for more information. If you have any questions and want to learn more about Thundra products, you can contact us at [email protected], join our community slack channel , connect with us on Twitter and LinkedIn.
And if you have yet to take your first step into the world of Thundra, you can begin your journey here.