Network probe

There is nothing to set up. No credential, no address, no wizard. Every tenant gets exactly one network probe, built in, and its tools are available to an investigation straight away.

It answers the most basic triage questions about a hostname the platform found in an alert: is this host reachable, is its certificate valid, and does its name resolve to what you expect.

What it adds to an investigation

This is what separates "our service is broken" from "our DNS record is pointing at nothing".

How it is wired

flowchart LR
    Inc["An investigation has a<br/>hostname from the alert"] --> Probe["Network probe<br/>no data source,<br/>no credential"]
    Probe --> Public["Public addresses only"]
    Public --> Thread["What someone outside your<br/>network would see"]

One path, and it is the only connector with nothing to configure. There is no data source to create and no credential to store, because it holds no access to anything of yours. It reaches only public addresses, which is what makes that safe.

Before you start

Nothing. It is on.

The Add connection catalog deliberately has no card for it, because a configurable copy would be misleading and could duplicate the built-in. It polls nothing, and it has nothing to look at until an investigation names a host.

What it can do

Tool	What it does
resolve_dns	Resolve a hostname to its A/AAAA addresses and CNAME chain (pure DNS lookup, no connection). Each address is tagged public true/false; a host that resolves into private/metadata space is REPORTED (a real misconfiguration signal), not hidden. Use to answer "where does this name point".
check_reachable	Open a single TCP connection to host:port and report reachability + latency (the "is it up" check). No data is sent or read. host may be a hostname or a public IP literal; port defaults to 443.
inspect_tls	Complete a TLS handshake to host:port and return the leaf certificate + trust verdict: subject, issuer, validity dates, SAN, fingerprint, negotiated protocol/cipher, computed daysToExpiry/expired, and authorized/authorizationError. Reports broken certs (expired, self-signed, wrong host) as data rather than failing. port defaults to 443.
http_meta	Send a single HTTP HEAD to a URL and return only the status code and response headers (no body is ever read). Redirects are NOT followed: a 3xx returns its status + Location for the model to probe as a fresh call. url must be http or https; the host may be a public IP literal.

One connection per call, with no ranges and no loops, so the tools cannot be used to scan a network. Timeouts are short: three seconds for a name lookup, five for a connection or a certificate check, eight for an HTTP request.

The target can be a hostname or a public IP address. A private or metadata address is refused either way.

Public addresses only, and why that matters here

Every other connector points at one server you configured. This one points wherever the incident says, which makes a hostname that resolves to an internal address the main threat rather than an edge case.

flowchart LR
    Name["A hostname from<br/>the incident"] --> Resolve["Resolve it once"]
    Resolve --> Judge{"Every returned<br/>address public?"}
    Judge -->|"No"| Refuse["Refused outright"]
    Judge -->|"Yes"| Dial["Connect to that<br/>exact address"]

It never looks the name up a second time. That closes the gap a general address check cannot: a name whose DNS answer changes between the check and the connection cannot land on an internal address, because the address that was checked is the address that gets dialled. An answer mixing a public and a private address is rejected outright, so there is no picking the safe-looking one.

Refused in all cases: loopback, private ranges, carrier-grade NAT, cloud metadata, unique-local, link-local, and every way of writing an IPv4 address inside an IPv6 one.

Your egress rules remain the backstop. See Network policy.

Why the certificate check accepts a bad certificate

Its entire purpose is to diagnose broken certificates. Refusing to complete the handshake would fail on exactly the expired, self-signed, and wrong-host certificates you are trying to look at.

So the handshake completes regardless, and the verdict is reported as data: whether it was trusted, and if not, why. Nothing is sent over that connection, no credential and no request body, so completing it exposes nothing.

Secrets in results

There is nothing to redact. The connector calls no authenticated API and returns no response body. Headers are metadata. A session cookie from an anonymous request is not a secret, and is covered by the platform's general redaction anyway.