Deployment Integrations
On-premise Integrations
Platform Integrations


What does zero overhead mean? How can I achieve that with Thundra?

If Thundra gathers data synchronously through Lambda calls, it will create some delay to your Lambda function execution. Remediation is to enable asynchronous monitoring. You can check out this part of the documentation or start directly with our to learn how to set up asynchronous monitoring.

Will my function take longer than before?

No. Once you set up asynchronous monitoring, our collector module will start to collect the monitoring data asynchronously. According to our benchmarks, we only add 2 ms to the invocation time on average. This is unique to Thundra and we are proud of it.

If you need to send your data synchronously, it'll add a minimal overhead to your application. It's 5 ms on average. We are continuously working to reduce the overhead and you can see our latest benchmarks here.

Will I experience loss of monitoring data?

No. Systems using synchronous monitoring should have a retry mechanism to make sure there is no data loss, as data sending may fail in some attempts. Retries result in latency or there could be data loss if there is no retry mechanism. Thundra solves these issues thanks to its asynchronous monitoring capability.

Can I hide or encrypt the monitoring data before sending Thundra?

Yes. By default, request and response of the invocation is not sent to Thundra. You can enable or disable it using environment variables. You can also manage to mask the objects, arguments, return values, local variables by serializing them using programmatic API. You can read more about it here.

Can I use Thundra for my functions within VPC?

Yes. Thundra doesn’t run along with your Lambda function; instead its tracing capabilities are injected to your function and log collection happens asynchronously through Amazon CloudWatch. That’s why VPC rules don’t apply to Thundra with asynchronous monitoring. For all other unique advantages of asynchronous monitoring, check out our blog post:

What is the point of API Key?

In Thundra, API keys are required to send monitor data. API keys are used for authentication, identifying requests, and applying rate limiting to the requests (as needed). In order to serve users better, we need to put a limit to number of requests per account. For now, the limit is set as 1000 requests per minute.

Can I distribute my request limit within my organization?

Yes. You can create multiple API keys to distribute your total request count to different teams within your organization. Note that the total limit for multiple API keys is still 1000 requests per minute.

What if my requests exceed the limit?

In this case, the exceeding requests are simply dropped. If you are using synchronous monitoring, you will face HTTP errors. If you are using asynchronous monitoring, you will see the error logs in CloudWatch logs.

I hit the limits of the plan, what will be happened?

When you hit the limits of your plan, we block your trace data. You can still continue to use Thundra however you can only monitor your invocation data.

When you doubled your limits without using tracing capabilities, you exceed a lot your allotment. That's why we restrict your Thundra usages. Until the next period of your plan, Thundra doesn't accept data and invocation. You can upgrade your plan from the billing page to continue using Thundra.

You can track your usages on the Report tab of billing page.

I have executed my AWS Lambda function but couldn’t see its metrics in the dashboard instantly‒ Why?

It takes 1-2 minutes to see your function’s monitor data in the application.

Can I use Thundra for AWS Lambda functions in different programming languages?

Thundra currently supports Lambda functions in Java, Node.js, Python, Go and .NET. Using the same API key, you can monitor functions in all of the supported languages.

I couldn’t find an answer to my question. How can I get help?

Just join our Slack channel, we'll be glad to assist you.

Thundra cannot subscribe to log group of the function. Why?

CloudWatch only allows one subscription per log group. If the log group already have a subscription filter, (such as Elasticsearch subscription filter or AWS Lambda subscription filter) you have to remove the existing filter shown as below.

Remove subscription filter on new UI
Remove subscription filter on old UI