Hello Splunkers, For an unknown reason, I'm not able to open a case so I'm describing the issue here today. I'm using the sim_forwarder_assets in my company to monitor the possible loss of UF & HF, it's working well and is easy to maintain. Today Splunk introduces an update (3.28.0) : https://docs.splunk.com/Documentation/SplunkCloud/9.2.2403/ReleaseNotes/CloudMonitoringConsole And since this update (around 2PM UTC), I'm experiencing a lot of HF & UF marked as "missing" but in fact they are not and they are working perfectly well.  So I dig in the scheduled search responsible of the build & maintain of the sim_forwarder_assets and  found the issue. Schedule Search Name : SIM SS - Forwarder Build Asset Table  The following macro at the top is the following : `sim_build_forwarder_assets(1m)` index=_internal sourcetype=splunkd TERM(group=tcpin_connections) TERM("cooked") OR TERM("cookedSSL") (hostname!=*.splunk*.*) fwdType!="edge" | lookup reserved-cidrs cidr_block AS sourceIp OUTPUT cidr_source | where isnull(cidr_source) So Splunk is searching for hosts that are not in the lookup reserved-cidrs, This lookups contains some of well-known multicast address and some reserved subnets over internet but it also contains some GCP IPs shared with customer :  34.0.0.0/15 gcp Public IP addresses for Google APIs and services including Google Cloud netblocks. However in my case and I believe in other customers too some on my HFs are presented on Splunk Cloud as with GCP Public IPs (34.X & 35.X) As most of the GCP supernets are present in this lookup, my HF are declared as "missing" due to that. I assume that Splunk should not include this kind of supernet in the lookup. I do not know if everything is clear and I'm sorry for my poor english :). ... View more