Update monitor details with state definitions and environment management instructions #11896
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Bundle ReportChanges will increase total bundle size by 950 bytes (0.0%) ⬆️. This is within the configured threshold ✅ Detailed changes
|
6 tasks
| description: "Learn how to navigate the Monitor Details page to help you understand your recurring job's overall health." | ||
| --- | ||
|
|
||
| The **Monitor Details** page is where you'll find a daily historical bar chart showing successful, failed, and missed check-ins and a line chart of the runtime average for the job execution. |
There was a problem hiding this comment.
The timeline is here too right?
Also it's actually an Area chat for the durations
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. | ||
|
|
||
| - **Active:** The monitor is currently accepting and processing check-ins. New Cron Monitor issues will be created for failed or missed check-ins according to your monitor configuration. | ||
| - **Muted:** The monitor and it's environments are accepting check-ins but will not create any Cron Monitor issues for failed or missed check-ins. This is useful when you want to temporarily disable alerting for a monitor. |
There was a problem hiding this comment.
timeouts too, not sure if you want to include that
lizokm
approved these changes
Nov 21, 2024
| --- | ||
| title: Monitor Details | ||
| sidebar_order: 1 | ||
| description: "Learn how to navigate the Monitor Details page to help you understand your recurring job's overall health." |
There was a problem hiding this comment.
Suggested change
| description: "Learn how to navigate the Monitor Details page to help you understand your recurring job's overall health." | |
| description: "Learn how to use Sentry's Monitor Details page to understand your recurring job's overall health." |
Comment on lines
+6
to
+11
|
|
||
| The **Monitor Details** page is where you'll find a daily historical bar chart showing successful, failed, and missed check-ins and a line chart of the runtime average for the job execution. | ||
|
|
||
| The "Issues" section shows the issues created from this Cron Monitor. Issues are created when a cron monitor job execution is missed or failed. If you have configured the Sentry SDK for your job, any errors thrown during the job runtime will be shown here as well. | ||
|
|
||
| The table of recent check-ins lists previously run jobs and their statuses. |
There was a problem hiding this comment.
Suggested change
| The **Monitor Details** page is where you'll find a daily historical bar chart showing successful, failed, and missed check-ins and a line chart of the runtime average for the job execution. | |
| The "Issues" section shows the issues created from this Cron Monitor. Issues are created when a cron monitor job execution is missed or failed. If you have configured the Sentry SDK for your job, any errors thrown during the job runtime will be shown here as well. | |
| The table of recent check-ins lists previously run jobs and their statuses. | |
| Clicking on a recurring job from the [**Cron Monitors**](https://sentry.io/orgredirect/organizations/:orgslug/crons/) page takes you to the **Cron Monitor Details** page. Here you'll be able to see: | |
| - Daily historical bar chart: Displays the number of successful, failed, and missed check-ins for the selected job. | |
| - Runtime line chart: Shows the average execution time for the job over time. | |
| If you scroll down to the "ISSUE" section, you'll see any issues created when a job execution missed or failed. If you've configured the Sentry SDK for your job, any errors thrown during the job runtime will be shown here as well. | |
| Just below, you'll find the table of "Recent Check-Ins" which lists previously scheduled jobs and their statuses. |
Comment on lines
+17
to
+28
| Sentry's Cron Monitoring service can notify you and store a timeline of the following check-in events: | ||
|
|
||
| - **Missed check-in:** The job didn't execute in the predicted timeframe or frequency. This can happen for various reasons, such as: | ||
| - The job scheduler is misconfigured, skipped, or failed to initiate your job. | ||
| - A timeout failure event when a job sent an initial check-in but failed to send a final check-in. | ||
| - Network issues, such as an outbound firewall or an unstable connection. | ||
| - An invalid request format. | ||
| - **Failed check-in:** The job has reported its execution as unsuccessful. | ||
| - **Successful check-in:** The job has reported its execution as successful. | ||
| - **Unknown check-in:** In rare occasions, it is possible that Sentry is unable to identify a check-in status. This can happen during outages or maintenance periods. | ||
|
|
||
| To see information about your cron monitor, select "Crons" from the sidebar menu and click on your cron monitor's name. |
There was a problem hiding this comment.
Suggested change
| Sentry's Cron Monitoring service can notify you and store a timeline of the following check-in events: | |
| - **Missed check-in:** The job didn't execute in the predicted timeframe or frequency. This can happen for various reasons, such as: | |
| - The job scheduler is misconfigured, skipped, or failed to initiate your job. | |
| - A timeout failure event when a job sent an initial check-in but failed to send a final check-in. | |
| - Network issues, such as an outbound firewall or an unstable connection. | |
| - An invalid request format. | |
| - **Failed check-in:** The job has reported its execution as unsuccessful. | |
| - **Successful check-in:** The job has reported its execution as successful. | |
| - **Unknown check-in:** In rare occasions, it is possible that Sentry is unable to identify a check-in status. This can happen during outages or maintenance periods. | |
| To see information about your cron monitor, select "Crons" from the sidebar menu and click on your cron monitor's name. | |
| Sentry's Cron Monitoring can notify you and store a timeline of the following check-in events: | |
| - **Missed check-in:** The job didn't execute within the expected timeframe or frequency because: | |
| - The job scheduler is misconfigured and skipped or failed to initiate your job. | |
| - A job sent an initial check-in, but failed to send a final check-in due to a timeout failure event. | |
| - There were network issues, such as an outbound firewall or an unstable connection. | |
| - An invalid request format. | |
| - **Failed check-in:** The job reported its execution as unsuccessful. | |
| - **Successful check-in:** The job reported its execution as successful. | |
| - **Unknown check-in:** In rare cases, Sentry may be unable to identify a check-in status due to an outages or maintenance period. | |
|
|
||
| ## Monitor State | ||
|
|
||
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. |
There was a problem hiding this comment.
Suggested change
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. | |
| A monitor can have three states: active, muted, and disabled. Disabled monitors don't count towards your plan's monitor limit. |
Comment on lines
+31
to
+42
|
|
||
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. | ||
|
|
||
| - **Active:** The monitor is currently accepting and processing check-ins. New Cron Monitor issues will be created for failed or missed check-ins according to your monitor configuration. | ||
| - **Muted:** The monitor and it's environments are accepting check-ins but will not create any Cron Monitor issues for failed or missed check-ins. This is useful when you want to temporarily disable alerting for a monitor. | ||
| - **Disabled:** The monitor and it's environments are not accepting check-ins, with any check-ins sent to a disabled monitor will be dropped. Disabled monitors do not count towards your plan's monitor limit. | ||
|
|
||
| <Alert level="info" title="Note"> | ||
| The monitor state supercedes the [environment state](#environment-state). If a | ||
| monitor is disabled or muted, so will all environments of it's environments, | ||
| regardless of their individual state. | ||
| </Alert> |
There was a problem hiding this comment.
Suggested change
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. | |
| - **Active:** The monitor is currently accepting and processing check-ins. New Cron Monitor issues will be created for failed or missed check-ins according to your monitor configuration. | |
| - **Muted:** The monitor and it's environments are accepting check-ins but will not create any Cron Monitor issues for failed or missed check-ins. This is useful when you want to temporarily disable alerting for a monitor. | |
| - **Disabled:** The monitor and it's environments are not accepting check-ins, with any check-ins sent to a disabled monitor will be dropped. Disabled monitors do not count towards your plan's monitor limit. | |
| <Alert level="info" title="Note"> | |
| The monitor state supercedes the [environment state](#environment-state). If a | |
| monitor is disabled or muted, so will all environments of it's environments, | |
| regardless of their individual state. | |
| </Alert> | |
| A monitor can have three states: active, muted, and disabled. Only disabled monitors do not count towards your plan's monitor limit. | |
| - **Active:** The monitor is accepting and processing check-ins. If a check-in fails or is missed, new Cron Monitor issues will be created based on your monitor's configuration. | |
| - **Muted:** The monitor and its environments accept check-ins, but won't create Cron Monitor issues for failed or missed check-ins. This is useful if you want to temporarily pause alerts without stopping check-ins. | |
| - **Disabled:** The monitor and its environments no longer accept check-ins. Any check-ins sent to a disabled monitor will be ignored. Disabled monitors don't count towards your plan's monitor limit. | |
| <Alert level="info" title="Note"> | |
| The monitor state supersedes the [environment state](#environment-state). If a monitor is disabled or muted, all of its environments will automatically inherit that state, regardless of their individual settings. | |
| </Alert> |
|
|
||
| To see information about your cron monitor, select "Crons" from the sidebar menu and click on your cron monitor's name. | ||
|
|
||
| ## Monitor State |
There was a problem hiding this comment.
Suggested change
| ## Monitor State | |
| ## Monitor States |
Comment on lines
+67
to
+74
| ## Multiple Environments | ||
|
|
||
| A monitor can be configured with multiple environments, with all environments running with the same schedule. Only environments with at least one check-in will be displayed and made available for alerting and filtering. | ||
|
|
||
| Although the schedule of check-ins of all environments are the same, the environment state and check-ins are independent of each other. This means that a missed or failed check-in in one environment will not affect the state of other environments. | ||
|
|
||
| If you're using one of Crons' [supported SDKs](/product/crons/getting-started/), the check-in environment will be automatically set to the environment configured in the SDK. If you're using the API, you can set the environment in the check-in payload. | ||
|
|
There was a problem hiding this comment.
Suggested change
| ## Multiple Environments | |
| A monitor can be configured with multiple environments, with all environments running with the same schedule. Only environments with at least one check-in will be displayed and made available for alerting and filtering. | |
| Although the schedule of check-ins of all environments are the same, the environment state and check-ins are independent of each other. This means that a missed or failed check-in in one environment will not affect the state of other environments. | |
| If you're using one of Crons' [supported SDKs](/product/crons/getting-started/), the check-in environment will be automatically set to the environment configured in the SDK. If you're using the API, you can set the environment in the check-in payload. | |
| ## Multiple Environments | |
| A monitor can be configured to run across multiple environments, all following the same schedule. However, only environments with at least one check-in will appear and be available for alerting and filtering. | |
| Although the check-in schedule is the same across all environments, each environment operates independently. This ensures that a missed or failed check-in in one environment won't impact the state of other environments. | |
| If you're using [an SDK that supports Crons](/product/crons/getting-started/), the check-in environment will be automatically set to the environment configured in the SDK. If you're using the API, you can set the environment in the check-in payload. | |
Comment on lines
+75
to
+83
| ## Environment State | ||
|
|
||
| Indepent of the monitor state, each environment can have one of the following states: | ||
|
|
||
| - **Healthy:** The environment's latest check-in was successful. | ||
| - **Unhealthy:** The environment's latest check-in was a failure or a miss. | ||
| - **Waiting for check-in:** The environment has not had any check-ins. | ||
| - **Muted:** The environment is muted and will not create any Cron Monitor issues. | ||
| - **Broken:** The environment has multiple failed or missed check-ins in a row. |
There was a problem hiding this comment.
Suggested change
| ## Environment State | |
| Indepent of the monitor state, each environment can have one of the following states: | |
| - **Healthy:** The environment's latest check-in was successful. | |
| - **Unhealthy:** The environment's latest check-in was a failure or a miss. | |
| - **Waiting for check-in:** The environment has not had any check-ins. | |
| - **Muted:** The environment is muted and will not create any Cron Monitor issues. | |
| - **Broken:** The environment has multiple failed or missed check-ins in a row. | |
| ## Environment State | |
| Each environment can have one of the following states independent of the monitor state: | |
| - **Healthy:** The environment's latest check-in was successful. | |
| - **Unhealthy:** The environment's latest check-in was a failure or miss. | |
| - **Waiting for check-in:** The environment hasn't had any check-ins. | |
| - **Muted:** The environment is muted and won't create any Cron Monitor issues. | |
| - **Broken:** The environment has had multiple failed or missed check-ins in a row. |
Comment on lines
+85
to
+97
| ### Broken Environments | ||
|
|
||
| Monitor environments that have been consistenly unhealthy for 14 days will be marked as broken. If no action is taken, Sentry will automatically mute the environment after 30 days of being broken. To recover a broken environment, a new healthy check-in must be sent. | ||
|
|
||
| ### Muting Environments | ||
|
|
||
| To mute an environment, you can do so from the monitor list or the monitor details page. | ||
|
|
||
| 1. Hover the environment state. | ||
| 2. Select "Mute Environment". | ||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Suggested change
| ### Broken Environments | |
| Monitor environments that have been consistenly unhealthy for 14 days will be marked as broken. If no action is taken, Sentry will automatically mute the environment after 30 days of being broken. To recover a broken environment, a new healthy check-in must be sent. | |
| ### Muting Environments | |
| To mute an environment, you can do so from the monitor list or the monitor details page. | |
| 1. Hover the environment state. | |
| 2. Select "Mute Environment". | |
|  | |
| ### Broken Environments | |
| Monitored environments that remain consistently unhealthy for 14 days will be marked as broken. If the issue persists and no action is taken, Sentry will automatically mute the environment after it's been broken for 30 days. To recover a broken environment, you'll need send a new healthy check-in. | |
| ### Muting Environments | |
| You can mute an environment from the monitor list or monitor details page. To do this: | |
| 1. Hover over the environment state. | |
| 2. Select "Mute Environment". | |
|  | |
Comment on lines
+98
to
+110
| ### Deleting Environments | ||
|
|
||
| To delete an environment, you can do so from the monitor list or the monitor details page. | ||
|
|
||
| 1. Hover the environment state. | ||
| 2. Select "Delete Environment". | ||
|
|
||
|  | ||
|
|
||
| <Alert level="danger" title="Caution"> | ||
| Deleting an environment will remove all check-in history associated with that | ||
| environment. | ||
| </Alert> |
There was a problem hiding this comment.
Suggested change
| ### Deleting Environments | |
| To delete an environment, you can do so from the monitor list or the monitor details page. | |
| 1. Hover the environment state. | |
| 2. Select "Delete Environment". | |
|  | |
| <Alert level="danger" title="Caution"> | |
| Deleting an environment will remove all check-in history associated with that | |
| environment. | |
| </Alert> | |
| ### Deleting Environments | |
| You can delete an environment from the monitor list or monitor details page. To do this: | |
| 1. Hover over the environment state. | |
| 2. Select "Delete Environment". | |
|  | |
| <Alert level="danger" title="Caution"> | |
| Deleting an environment will remove all of its check-in history. | |
| </Alert> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates the Cron "Monitor Details" page to include different state definitions for the monitor, environments, and how to manage them.
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES