Select an HTTP monitor in the Synthetic monitors page to open the Synthetic details page, which provides an overview of monitor execution results, their visualization, and monitor properties. Powered by the Dynatrace AI engine Davis, the Synthetic details page shows you at-a-glance information and graphs, with ready filters to drill right down to problem details.
When you select an HTTP monitor in the Synthetic monitors page, you see a toggle that enables you to try out the new UI for HTTP monitor details. Turn on the toggle to enable the new details page for all HTTP monitors in your environment.
For now, you can switch back and forth between the new and old versions of the details page so you can compare them. We welcome your feedback using the button provided. If you dismiss the panel at the top of your details page, the panel moves to the bottom of the page.
Metrics and visualizations
Use the filter bar at the top of the page to filter all Synthetic details by one or more locations.
Select the quick links in the upper-left corner to go directly to different cards in the details page or to access HTTP monitor settings (Edit, Disable, Delete).
Purple bars above the availability or performance timelines indicate maintenance windows.
- Whether or not you see problems and receive alert notifications during maintenance windows depends on how you configure the maintenance windows.
- Maintenance windows may be excluded from availability calculations by applying a global setting.
The availability infographic at the top of the page displays the monitor's availability for the selected timeframe, with details of outages, if any. If the monitor has an outage, global or local (defined in monitor settings), the box is displayed in red. Note that a monitor can be unavailable at one or all locations even if no outage thresholds have been set up. The outage duration is the sum of all outages (global and local) in the selected timeframe, not counting overlapping outages.
The Availability card shows overall availability across all monitor locations, with annotations for global/local outages and global/local missing data (as when the monitor is disabled). Hover over the overall availability graph to view information about the number of locations with outages or missing data at any given point in time.
Optionally, use the toggle to Show availability breakdown per location. Note that if you filter the entire details page by any locations, the toggle is no longer available.
The performance infographic at the top of the details page displays the HTTP monitor's average performance, that is, response time for the sum of all requests, for the selected timeframe. Additional metrics are captured per request and are shown in the requests card.
The Performance card shows trend lines for minimum and maximum response time for the sum of all requests, with the shaded area representing the difference between the two values at any given time. Note that if your monitor runs from a single location, the minimum and maximum trend lines coincide.
Optionally, use the toggle to Show response time breakdown per location. Note that if you filter the entire details page by any locations, the toggle is no longer available.
If the monitor violates a performance threshold, whether for the sum of all requests or an individual request, a solid red line appears above the performance graph for the duration of the problem. Additionally, any threshold for the sum of all requests appears as a dotted red line.
Select the solid red bar to display a link to the problem overview page.
The Response size card shows trend lines for minimum and maximum response size for all requests, with any shaded area representing the difference between the two values at any given time. The trend lines might coincide (as shown below), as when your monitor runs from a single location. However, response size might vary, for example, when different responses are sent based on location.
To track such differences, you can optionally Show response size breakdown per location. Note that if you filter the entire details page by any locations, the toggle is no longer available.
An HTTP monitor can consist of one or multiple HTTP requests. The HTTP requests card gives you an overview of all executed requests, their order, name, and the HTTP method used. For each request, the HTTP requests card splits performance (Response time) by the following metrics (see more in HTTP monitor metrics):
- DNS lookup time
- TCP connect time
- TLS handshake time
Response time is the summation of these different metrics.
Expand a request from the list to view all performance metrics in one chart. Select a metric in the legend to remove/add it to the performance chart. Select Edit request to go to monitor settings from this card.
When a request is in violation of its event-specific performance threshold, it is highlighted in red. Expand the request to see the performance timings and the threshold violated. A solid red line appears above the stacked graph for the duration of the problem; the request threshold appears as a dotted red line. Select the solid red bar to display a link to the problem overview page.
This informational card shows the number of requests, locations, frequency of monitor execution, and any applied tags. You can also see the consumption of DEM units in the selected timeframe. Select Add tag to apply additional tags. Note that tags can only applied and deleted from the details page.
The Services card appears when the endpoint being monitored is hosted on a OneAgent-monitored host. The card displays the automatically associated monitored services. Select the link for a displayed service to view the service overview page, filtered by the HTTP monitor.
HTTP monitors enable you to monitor internal resources and API endpoints, for example, for key back-end APIs for login or search operations used by your mobile apps. You can link such HTTP monitors to the monitored mobile, web, or custom applications. Select Assign monitor to application. (You can link an application directly in monitor settings.)
If Real User Monitoring (RUM) is enabled for the applications your synthetic monitor runs against, Dynatrace automatically links the RUM applications to the monitor, and the Monitored applications card is displayed. You can see the key metrics of the application and can jump directly to RUM data from here.
After you've linked an HTTP monitor to an application, synthetic monitor availability is displayed directly on the application overview page, and Davis automatically associates detected synthetic monitoring problems with the linked application.
The Problems card shows performance (threshold violation) and availability (local or global outage) problems when you enable the respective thresholds in monitor settings. Expand the card to see active as well as resolved problems for the selected timeframe.
See Configure HTTP monitors for information on how to define performance and availability thresholds. See Synthetic calculations for how availability and performance are calculated and how problems are generated and dismissed. See the Synthetic alerting overview for alerting workflow and concepts, including setting up notification profiles and templates.
There are three main problem types for HTTP monitors:
- Global outage (availability)
- Local outage (availability)
- Performance threshold violation (performance problem for sum of all requests or individual requests)
- Performance problems may combine threshold violations at the monitor as well as the event levels.
- Concurrently occurring problems may be combined into a single problem (Multiple applicatation problems).
Select a problem to view the problem overview page.
The Events card shows all events that compose problems. Events for active as well as resolved problems show up in the list and timeline.
Hover over a time slot in the event timeline to see the type and number of events generated in that interval. Select a time slot and display the events that took place in it.
Select an event type, for example, HTTP monitor location slowdown, to see the list of events. There is always one slowdown event created per location where your monitor violates request- or monitor-level performance thresholds. Select an individual event to see details.
HTTP status codes
The HTTP status codes card displays the timeline of returned HTTP status codes for your HTTP monitor executions as a whole, which is the status code for the last executed request in the monitor, whether successful or failed. If your monitor has multiple requests, say three, and the monitor fails at the second request, the third request is not executed. The status code reported is for the second request.
Hover over any time slot in the timeline to see the count of different status codes during that interval.