---
title: Status Events
description: >-
  View and manage monitor events on the status page including quick actions,
  event details, and troubleshooting tools.
breadcrumbs: Docs > Monitors > Monitor Status > Status Events
---

# Status Events

{% alert level="info" %}
Status Events is part of the [provisional Monitor Status Page](https://docs.datadoghq.com/monitors/status/status_page.md). If you are using the legacy status page, see the [Status Page (Legacy)](https://docs.datadoghq.com/monitors/status/status_legacy.md) documentation.
{% /alert %}

## Overview{% #overview %}

{% image
   source="https://docs.dd-static.net/images/monitors/status/status_page_event_details.36caee4d912f089eb974978f076d1c77.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/status/status_page_event_details.36caee4d912f089eb974978f076d1c77.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Monitor status page displaying event details" /%}

All events generated by your monitor appear on the monitor's status page, showing the groups' name, event type, and timestamp. The Event timeline also includes downtime and audit trail events.

For each event, you can access quick actions and view related assets, like dashboards and logs.

## Event details section{% #event-details-section %}

To explore each individual event for more information, including associated tags and actions:

1. From the monitor status page, scroll down to the **Event timeline.**
1. Click on an event in the timeline to view event details.

Use the event details to understand monitor alerts and identify root causes. This information supports responder workflows and helps you stay informed about ongoing situations.

### Take action to remediate{% #take-action-to-remediate %}

With Quick Actions, you can take action without leaving the status page. Responders save time since the context is automatically added.

| Action           | Description                                                                                                                                                                         |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Mute             | Create a [downtime](https://docs.datadoghq.com/monitors/downtimes.md?tab=bymonitorname) to mute monitor alerts.                                                                     |
| Resolve          | Temporarily set the monitor status to `OK` until its next evaluation.                                                                                                               |
| Declare Incident | Escalate monitor alerts with [Incident Management](https://docs.datadoghq.com/incident_response/incident_management.md).                                                            |
| Create Case      | Create a [case](https://docs.datadoghq.com/incident_response/case_management.md) to keep track of this alert investigation without leaving Datadog.                                 |
| Run Workflow     | Run [Workflow](https://docs.datadoghq.com/service_management/workflows/trigger.md#trigger-a-workflow-from-a-monitor) Automation with predefined snippets to run mitigation actions. |

### Resolve{% #resolve %}

You can resolve a monitor alert from the status page [Header](https://docs.datadoghq.com/monitors/status/status_page.md#header) or Event details sections. Resolving from the Event details section only affects the group related to the selected event, while resolving from the Header resolves all groups in the alert and sets the monitor status to `OK` (all groups).

If a monitor is alerting because its current data corresponds to the `ALERT` state, using `resolve` will cause the state to temporarily switch from `ALERT` to `OK`, and then back to `ALERT`. Therefore, `resolve` is not meant for acknowledging the alert or instructing Datadog to ignore it.

Manually resolving a monitor is useful when data is reported intermittently. For example, after an alert is triggered, the monitor may stop receiving data, preventing it from evaluating alert conditions and recovering to the `OK` state. In such cases, the `resolve` function or the `Automatically resolve monitor after X hours` changes the monitor back to an `OK` state.

**Typical use case**: A monitor based on error metrics that are not generated when there are no errors (`aws.elb.httpcode_elb_5xx`, or any DogStatsD counter in your code reporting an error *only when there is an error*).

## Event troubleshooting section{% #event-troubleshooting-section %}

{% image
   source="https://docs.dd-static.net/images/monitors/status/events/event_troubleshooting.8794231e90159cceb3f8f1690ed21946.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/status/events/event_troubleshooting.8794231e90159cceb3f8f1690ed21946.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Event troubleshooting with an example dependency map" /%}

For each event, access troubleshooting information to help responders quickly understand the context of the alert.

| Troubleshooting component | Description                                                                                                                                                                                                                                                                                                                  |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dependency Map            | When a service tag is available, either as a monitor tag or in the group, you can access a dependency map showing the status of your dependencies.                                                                                                                                                                           |
| Change Tracking           | When a service tag is available, either as a monitor tag or in the group, you can access a list of relevant changes to your service and its dependencies. For details on specific types of supported changes and setup requirements, see the [Change Tracking](https://docs.datadoghq.com/change_tracking.md) documentation. |

## Further reading{% #further-reading %}

- [Event Management](https://docs.datadoghq.com/service_management/events.md)