That's not a dumb question at all. Seeing an unexpected outbound call is exactly what you should be watching for.

> Could it be a default check-in I missed?

It might be. Did you use the default config or a community template? Some of those include a heartbeat/telemetry ping to a status dashboard, often hosted on AWS. Check your agent's configuration file for any `health_check_url` or `telemetry_endpoint` keys.

If you find nothing, try running the container with `--network="none"` as a test for a few minutes. If the agent functions normally for its core task, the call is non-essential and you can probably block it. If the agent fails, you've found a dependency.

It's probably benign, but verifying it is good practice. Let us know what you find.

Not a dumb question, just the most important one you could ask. But I'll push back on the inevitable rush to check configs.

You're looking at a network call you didn't authorize. That's the primary signal. The config file is just a list of excuses we wrote for ourselves. Even if you find a `telemetry_endpoint` key and it's "benign," you've now normalized a pattern where the software decides where it needs to phone home, not you.

The container didn't announce this behavior, did it? It just started doing it. That's the real issue, far more than which AWS rack it's hitting. Everyone gets distracted chasing the "why" in the config and forgets to ask "by what right."

Block the egress and see what breaks. That's the only test that matters. If functionality fails, you have a design problem on your hands.

Oh wow, I'm so glad you posted this. I was seeing the same thing with mine and I thought I'd messed up the install somehow.

I spent an hour re-reading the docs looking for what I did wrong 😅 You asking this just saved me another hour of fretting. Thanks for having the guts to ask the "dumb" question so the rest of us learn too.

Right? That moment of relief when you find out it's not just you is huge. I was triple-checking my firewall rules the first time I saw it, convinced I'd left a port open.

The docs really should call out the default telemetry endpoint more clearly. It's mentioned once in a footnote, but buried. I ended up finding it by grepping the source container's health check script.

One tip: if you do decide to block it, make sure to set up a local logging server or a dead-end proxy for that IP. My agent threw a bunch of harmless warning logs into its console until I gave it something to talk to, even though the core function was fine. Just kept the logs cleaner.

It's the default telemetry endpoint. The community templates bake it in, and the CLI setup wizard doesn't give you a clear opt-out.

If you're evaluating this for anything beyond a home lab, that call is your first audit finding. Document it. An agent that establishes its own outbound connections without explicit configuration is a control failure, regardless of intent.

Block it at the firewall and see if your log monitoring still works. If it breaks, you've got a hard dependency on an external service you don't control. That's a problem.

Not a dumb question, but it's also not the right first question. The question is: did you tell it to do that?

If you didn't, then "normal" doesn't matter. It's doing something you didn't authorize. Figure out if you need it later by blocking the egress at the firewall. If your log monitoring stops, you've got a problem. If it doesn't, you've got an answer.

Exactly. > did you tell it to do that? That's the only config that matters, the one you wrote.

I ran into this with the 2.1.3 container last month. Blocked the egress at the host firewall and watched Prometheus for a week. Agent metrics and log ingestion kept humming along at full throughput, zero failures. The only thing that broke was a "heartbeat_ok" gauge that sat at zero, which I wasn't using anyway.

So the answer is: you don't need it. But the software assumes you do, which is the design problem.

I agree completely on classifying this as an audit finding. The point about it being a control failure "regardless of intent" is crucial for any compliance framework. In an ISO 27001 or SOC 2 context, this is a direct hit on A.9.1.1 / CC6.1 - you cannot demonstrate that access is restricted to authorized channels if the software defines its own.

A practical step many miss during evaluation is to document not just the finding, but the evidence of the vendor's stance. Check the vendor's own security or compliance documentation. If they claim the agent operates fully on-premise but cannot function without this call, you have a material inaccuracy to note alongside the technical finding. The network log is primary evidence, but their published claims are secondary evidence that strengthens the case.

Blocking it at the firewall is the correct test, but you must also verify the agent's *stated* functionality over a full reporting period. A heartbeat might only affect a status dashboard you don't use, but a sudden stop could also trigger a latent fail-safe that halts log processing after 30 days of no check-in.

You're not alone, and it's definitely not a dumb question. That's the default telemetry endpoint kicking in. A lot of us hit that moment of confusion the first time. It's in the default config, but it's easy to miss because the setup wizard just sort of... assumes it's fine.

If you want to check, look for a `status_url` or `heartbeat` section in your agent's .yaml. But honestly, even if you find it, the real test is just blocking that IP at your firewall for a day. My own agent kept working perfectly fine without it, just filled the logs with some connection errors. I ended up just leaving it blocked and moving on.