# \[Bug\] Elastic Agent reports healthy even if two integrations set up which listen on the same tcp port which doesnt work
**URL:** https://discuss.elastic.co/t/bug-elastic-agent-reports-healthy-even-if-two-integrations-set-up-which-listen-on-the-same-tcp-port-which-doesnt-work/376901
**Category:** Elastic Agent
**Created:** [April 8, 2025, 10:47am UTC](https://discuss.elastic.co/t/bug-elastic-agent-reports-healthy-even-if-two-integrations-set-up-which-listen-on-the-same-tcp-port-which-doesnt-work/376901 "2025-04-08T10:47:14Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@fbpolar](https://discuss.elastic.co/u/fbpolar)
#### Post date: [April 8, 2025, 10:47am UTC](https://discuss.elastic.co/t/bug-elastic-agent-reports-healthy-even-if-two-integrations-set-up-which-listen-on-the-same-tcp-port-which-doesnt-work/376901/1 "2025-04-08T10:47:15Z")
When setting up two custom tcp integrations on the same elastic agent, it reports being healthy, even if the second integration doesnt work since it cannot listen on the same port as the first tcp integration.
Reproduce:
1. Install custom tcp integration, listen on some port like 8080 on 0.0.0.0
2. Add integration to some policy with some agent
3. Set up a second custom tcp integration, listen again on the same port e.g. 8080 on 0.0.0.0
4. Add integration to same policy with same agent
5. Agent reports being healthy
Moreover, even worth is that if you delete the first integration which was listening successfully on the port, the second will not start listening on the port subsequently. This means that you run into a state where you have the second integration setup and it is not working as intened.
Instead, you have to remove the integration again and then add it to the agent again in order to get the port listening working again.
This is a bug as far as I see and if that can be confirmed, I will open an issue on GitHub. Customers had problems with this, and I investigated for them đŸ™‚
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [April 8, 2025, 1:54pm UTC](https://discuss.elastic.co/t/bug-elastic-agent-reports-healthy-even-if-two-integrations-set-up-which-listen-on-the-same-tcp-port-which-doesnt-work/376901/2 "2025-04-08T13:54:49Z")
One issue here is that by design the Agent reports the health status based mainly if it can talk with fleet or not.
If it can output data or not or if it is having some issues with the input is not taken into consideration in some cases.
I opened an issue about this a couple of months ago:
>
>
> \*\*Describe the feature:\*\*
>
> An Elastic Agent health status should take into consi…deration if the Agent can send data to the configured output or not, currently if the Agent can connect with the Fleet Server, it will be marked as \`HEALTHY\` independently if it can or can not send data to configured output.
>
> You may have an agent the can connect with the fleet server, but it is having issues connecting with the configured output, so you will have no data from this agent, but it is still marked as HEALTHY, when it should be marked as UNHEALTHY, or a different new status.
>
> Today this is how it works:
>
> !\[Image\](https://github.com/user-attachments/assets/ce8e9995-abab-4980-8b7b-2296c3143755)
>
> But this is how it should work:
>
> !\[Image\](https://github.com/user-attachments/assets/39025396-61ea-4270-ba88-da4891dec62f)
>
>
> \*\*Describe a specific use case for the feature:\*\*
>
> The user may have some network limitations or issues in their infrastructure and sometimes it is not easy to identify or troubleshoot those issues, making it clear if the agent can send data or not helps identify agents that are having network issues.
>
> For example, you may thousands of agents in multiple networks, if just a couple of them are in a network that is having issues sending data, but are able to connect with Fleet, it may be pretty hard to identify the agents with issues because there are no disctinction in the health status.
>
> Knowing which agent is UNHEALTHY because it cannot send data would make it easier to troubleshoot and solve the underlying issue.