Rephrase for clarity

Author: ralarcon

articles/azure-functions/configure-monitoring.md

@@ -298,24 +298,23 @@ Depending on how the telemetry generated is going to be consumed, real-time dash
 
 * **Tune your functions telemetry**: with the default log level set to `Error` or `Warning`, no detailed information from each function will be gathered (dependencies, custom metrics, custom events, and traces). For those functions that are key for production monitoring, define an explicit entry for `Function.<YOUR_FUNCTION_NAME>` category and set it to `Information`, so you can gather detailed information. At this point, to avoid gathering [user-generated logs](functions-monitoring.md#writing-to-logs) at `Information` level, set the `Function.<YOUR_FUNCTION_NAME>.User` category to `Error` or `Warning` log level.
 
-* **Host.Aggregator category**: as described in [Configure categories](#configure-categories), this category provides aggregated information of function invocations. The information from this category is gathered in Application Insights `customMetrics` table, and it's shown in the function Overview tab, at the Azure portal. If you set this category to other value different than `Information`, you will stop gathering the data in the `customMetrics` table and will not be displayed function details at the Azure portal. Depending on how you configure the aggregator, consider that there will be a delay (determined by the `flushTimeout`) in the telemetry gathered.
+* **Host.Aggregator category**: as described in [Configure categories](#configure-categories), this category provides aggregated information of function invocations. The information from this category is gathered in Application Insights `customMetrics` table, and it's shown in the function Overview tab in the Azure portal. If you set this category to other value different than `Information`, you will stop gathering the data in the `customMetrics` table and will not be displayed function details at the Azure portal. Depending on how you configure the aggregator, consider that there will be a delay (determined by the `flushTimeout`) in the telemetry gathered.
 
   The following screenshot shows Host.Aggregator telemetry data displayed in the function Overview tab.
   :::image type="content" source="media/configure-monitoring/host-aggregator-function-overview.png" alt-text="Screenshot of Host.Aggregator telemetry displayed in function Overview tab." lightbox="media/configure-monitoring/host-aggregator-function-overview-big.png":::
 
   The following screenshot shows Host.Aggregator telemetry data in Application Insights customMetrics table.
   :::image type="content" source="media/configure-monitoring/host-aggregator-custom-metrics.png" alt-text="Screenshot of Host.Aggregator telemetry in customMetrics Application Insights table." lightbox="media/configure-monitoring/host-aggregator-custom-metrics-big.png":::
 
-* **Host.Results category**: as described in [Configure categories](#configure-categories), this category provides the runtime-generated logs indicating the success or failure of a function invocation. The information from this category is gathered in the Application Insights `requests` table, and it is shown in the function Monitor tab, and in different Application Insights dashboards (Performance, Failures...). If you set this category to other value different than `Information`, you will stop gathering the data in the `requests` table and will not be displayed it the mentioned dashboards.
+* **Host.Results category**: as described in [Configure categories](#configure-categories), this category provides the runtime-generated logs indicating the success or failure of a function invocation. The information from this category is gathered in the Application Insights `requests` table, and it is shown in the function Monitor tab and in different Application Insights dashboards (Performance, Failures...). If you set this category to other value different than `Information`, you will stop gathering detailed data in the `requests` table and will not be displayed it the mentioned dashboards (for example, setting it to `error` results in tracking requests data only for failed executions).
 
   The following screenshot shows the Host.Results telemetry data displayed in the function Monitor tab.
   :::image type="content" source="media/configure-monitoring/host-results-function-monitor.png" alt-text="Screenshot of Host.Results telemetry in function Monitor tab." lightbox="media/configure-monitoring/host-results-function-monitor-big.png":::
 
   The following screenshot shows Host.Results telemetry data displayed in Application Insights Performance dashboard.
   :::image type="content" source="media/configure-monitoring/host-results-application-insights.png" alt-text="Screenshot of Host.Results telemetry in Application Insights Performance dashboard." lightbox="media/configure-monitoring/host-results-application-insights-big.png":::
 
-* **Host.Aggregator vs Host.Results**: both categories provide good insights about function executions, if needed, you can remove the detailed information from one of these categories, so your monitoring and alerting will be based on the other.
-
+* **Host.Aggregator vs Host.Results**: both categories provide good insights about function executions, if needed, you can remove the detailed information from one of these categories, so you can use the other for monitoring and alerting.
 Here's a sample:
 # [v2.x+](#tab/v2)