Is your improvement related to a problem? Please describe.
The throughput Connection Test presents "no throughput data recorded" as a hard connection failure, which overstates the problem and misleads users.
✗ Monitoring
Learn how to configure monitor instances
No throughput from Monitoring recorded in the last 30 days
Listening on queue ServiceControl.ThroughputData
In the screenshot the Monitoring instance is healthy and correctly configured. It is running, it is reachable, and it is listening on ServiceControl.ThroughputData — the diagnostics text says so itself. The only thing that has not happened is that no throughput has been reported to it in the last 30 days.
ServicePulse nevertheless renders this as a failure:
- A red ✗ (
faTimes / text-danger) next to Monitoring in ConnectionResultView.vue, which is strictly binary — it branches on ConnectionSettingsTestResult.connection_successful with no third state.
- The
SetupView banner reads "The connection to ... was not successful."
hasErrors in ThroughputStore.ts goes true, which puts a red exclamation mark on the Configuration item in the nav (ConfigurationView.vue).
So a working system is flagged as broken, in three places at once.
The underlying signal is coming from ServiceControl: licensing/settings/test returns connection_successful: false for the Monitoring source when no throughput has been recorded, even though nothing about the connection failed. An absence of data is not evidence of a broken connection. There are entirely legitimate reasons for it:
- A brand-new or recently reconfigured installation that has not accumulated data yet.
- Endpoints that have not enabled metrics (
EnableMetrics() / SendMetricDataToServiceControl(...)), so nothing is being reported to the Monitoring instance in the first place.
- A genuinely idle system.
Compounding this, the message is a dead end: it tells the user what was not found, but nothing about why that might be or what to do next. The panel's only link ("Learn how to configure monitor instances") points at the Monitoring instance's own config file, which is typically not the thing that is missing — the Monitoring instance is fine. What is usually missing is metrics configuration on the endpoints.
Describe the suggested solution
The Monitoring connection test result should distinguish "we could not connect" from "we connected fine, but there is no data to report", and it should give the user somewhere to go:
- Use a non-alarming indicator for the no-data case — a question mark, or a warning rather than a hard error. Reserve the red ✗ for an actual connection failure.
- The no-data case should not, on its own, escalate to the red error indicator on the Configuration nav item.
- Include an actionable hint alongside the message, e.g. "Do you have metrics enabled on your endpoints?", linking to the relevant guidance (monitoring metrics setup).
Note that the messages themselves (diagnostics) and the connection_successful flag originate in ServiceControl, so a complete fix likely spans both repositories — ServiceControl needs to be able to express this third state before ServicePulse can render it.
Describe alternatives you've considered
Fixing the wording alone in ServiceControl's diagnostics text, without changing the indicator. Rejected: the red ✗ and the resulting error state on the Configuration nav item are what actually communicate "something is broken", so softer text on its own would not stop users from believing their Monitoring instance has failed.
Is your improvement related to a problem? Please describe.
The throughput Connection Test presents "no throughput data recorded" as a hard connection failure, which overstates the problem and misleads users.
In the screenshot the Monitoring instance is healthy and correctly configured. It is running, it is reachable, and it is listening on
ServiceControl.ThroughputData— the diagnostics text says so itself. The only thing that has not happened is that no throughput has been reported to it in the last 30 days.ServicePulse nevertheless renders this as a failure:
faTimes/text-danger) next to Monitoring inConnectionResultView.vue, which is strictly binary — it branches onConnectionSettingsTestResult.connection_successfulwith no third state.SetupViewbanner reads "The connection to ... was not successful."hasErrorsinThroughputStore.tsgoes true, which puts a red exclamation mark on the Configuration item in the nav (ConfigurationView.vue).So a working system is flagged as broken, in three places at once.
The underlying signal is coming from ServiceControl:
licensing/settings/testreturnsconnection_successful: falsefor the Monitoring source when no throughput has been recorded, even though nothing about the connection failed. An absence of data is not evidence of a broken connection. There are entirely legitimate reasons for it:EnableMetrics()/SendMetricDataToServiceControl(...)), so nothing is being reported to the Monitoring instance in the first place.Compounding this, the message is a dead end: it tells the user what was not found, but nothing about why that might be or what to do next. The panel's only link ("Learn how to configure monitor instances") points at the Monitoring instance's own config file, which is typically not the thing that is missing — the Monitoring instance is fine. What is usually missing is metrics configuration on the endpoints.
Describe the suggested solution
The Monitoring connection test result should distinguish "we could not connect" from "we connected fine, but there is no data to report", and it should give the user somewhere to go:
Note that the messages themselves (
diagnostics) and theconnection_successfulflag originate in ServiceControl, so a complete fix likely spans both repositories — ServiceControl needs to be able to express this third state before ServicePulse can render it.Describe alternatives you've considered
Fixing the wording alone in ServiceControl's diagnostics text, without changing the indicator. Rejected: the red ✗ and the resulting error state on the Configuration nav item are what actually communicate "something is broken", so softer text on its own would not stop users from believing their Monitoring instance has failed.