You can obtain your workload status in two ways, automatic and static:
- Automatic status: it is calculated from a series of rules.
- Static status: it overrides any automatic calculation of your workload status.
To create or edit the workload status, click the Status details and setup icon from the workload overview.
You must have workload management permissions to carry out this configuration.
You can use the status of each one of the entities that belong to a workload in order to summarize the workload status into a single value.
Not all entities in a workload are equally important from a performance, errors, or availability perspective:
- You might want your workload to show as disrupted if an essential Synthetics monitor or service has got a critical violation going on.
- However, if your host infrastructure has a certain redundancy and resilience to outages, you might not need to change your workload status from Operational just because a single host has an alert violation going on.
By default, when you create a workload the following rules to calculate its status are added:
- For entity types close to the digital experience (that is, synthetic monitors, browser applications, mobile applications, and services), the worst available status is propagated.
- For any other entity type, which are basically infrastructure entities, the best available status is propagated.
To customize the automatic workload status, you can define your own rules. A rule consists of a group of entities and a roll up mode:
- Define the group of entities based on entity types, tag values, GUIDs, or a combination of all of them.
- Decide how to propagate the status of these entities to the group status:
- Roll up the best status: the group status matches the less critical status of all belonging entities. Use this option when you want the group status to be operational as long as at least one entity in the group is still operational.
- Roll up the worst status: the group status matches the most critical status of all belonging entities. Use this option when you want the group status to indicate a degradation or a disruption of service as soon as one entity in the group is not operational. You can also decide to roll up the worst status only after a certain amount of entities are not operational.
- Save the rule and proceed to create another one if you need to.
The final workload status equals the worst status among all the individual group statuses.
In this final calculation, any automatically calculated status is overridden if a static status has been set by a workload manager.
For an easier and more dynamic status configuration, you can use a roll-up type for all entities that aren’t evaluated in any other rule that you have defined before. In particular, if you don't add any other rule at all, the rule for remaining entities will take into account all the entities in the workload.
When combined with the grouping by entity type option, this special rule allows you to get a general sense of how each entity type in your workload is doing, without having to configure a rule for each entity type. Therefore, we recommend that you always set a rule for all remaining entities grouped by type, and roll up their worst status to quickly detect when all entities in a layer of your workload stack are not operational.
If you want to communicate the status for your workload regardless of any automatic calculation based on rules, you can set a static status value for your workload from one of the available status values.
This is useful during maintenance tasks to communicate to other teams that the status of your workload is disrupted, to provide further information, or to give the time you expect the workload to be operational again.
If you regularly need to communicate a temporary status due to your deployment or operations processes, you can automate the static status set up by integrating the API into your workflows.
Any static status set by a workload manager always overrides any other status values calculated automatically.
To set up a static workload status:
- Set a static status value.
- Optionally, write a short summary for the status, and a longer description of what’s happening to the workload.
- Check that the static status is enabled.
The workload Overview shows the result of the workload status. If you click on the Status details and setup icon (or just Status details if you don’t have the workload manager role), you’ll see how the status calculation was configured, and the result of all the rules and/or static statuses that were taken into account to calculate the global workload status value.
Any change that you make on the workload status configuration will become effective only once you save the changes. For your convenience, while you’re setting the automatic rules or a static status, you’ll get a preview of what the status result would be if you saved the configuration at that point.
If you need more help, check out these support and learning resources:
- Browse the Explorers Hub to get help from the community and join in discussions.
- Find answers on our sites and learn how to use our support portal.
- Run New Relic Diagnostics, our troubleshooting tool for Linux, Windows, and macOS.
- Review New Relic's data security and licenses documentation.