ECC Queue Inputs for SystemCommand probes stay in Ready state, giving the customer the impression there is a performance issueDescriptionSystemCommand probes don't have a sensor business rule (apart from grabLog/grabSettings), and so the Inputs remain in Ready state in the ECC Queue. This leads customers to believe there is a backlog or performance issue with the ECC Queue or MID Severs, when it does not. This causes confusion and delay when investigating MID Server and ECC Queue performance. e.g. System Command inputs where 'Source' is one of these would be left, apparently stuck, in Ready state:CitChangedCustomOperationChangedCustomParsingStrategyChangedFileChangeLibsApplCategoryChangedLibsDeviceInfoCategoryChangedMetadataRulesChangedPatternExtensionChangedautoUpgradeclear_cookiescredentials_reload - however a huge number of these might suggest an issue with OAuth2 credentials, and their token refresh.deleteExpiredIHubPlansfile_discovery_whitelist - You can expect lots of theseinvalidate_cacheload_propertiesprobe_cacherange_cacheresetQueryWindowrestartsignature_validation_certs_reloadupdateConfigSteps to Reproduce Look in the ecc_queue for Inputs apparently stuck in Ready state, especially on instances using Discovery and ACC heavily, or synchronous REST/SOAP integrations that wouldn't have a sensor.If you are under the impression that Ready Inputs indicate a performance issue or backlog, as most customers are, this looks like an issue, when it isn't, causing support cases to be opened.WorkaroundThis problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available. The "There is no Sensor" bit of article KB0718589 Why are my MID Server-related Jobs stuck and ECC Queue inputs still in Ready State? explains why this is likely to be a false assumption, and lists other possibilities for inputs remaining in ready state.Related Problem: PRB1979034