You can obtain your workload status in two ways:
- Automatic status: status is calculated from a series of rules.
- Static status: status overrides any automatic calculation of your workload status.
To manage workload status settings, go to a workload's Health status page.
Configure the automatic workload status
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 synthetic monitor or service has got a critical incident 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 incident 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.
Create custom rules
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.
Importante
In this final calculation, any automatically calculated status is overridden if a static status has been set by a workload manager.
A rule for remaining entities
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.
Importante
After six months of inactivity, we will automatically stop the status calculation. You can reactivate it by accessing the Workload and setting it to active.
Set a static workload status
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.
Dica
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.
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.
Any configured static status always overrides any other status values calculated automatically.
Understand the status value
If you go to the Health status page, you can 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 to the 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.
