Service Prioritization

Overview

The Service Prioritization feature allows you to assign priority tiers to services discovered within a given scope.
By default, all services are assigned a Service Level Objective (SLO) and treated as Critical.
However, not all services are equally important. Some require immediate attention, while others can be deprioritized or hidden entirely.

This feature helps teams focus on what matters, ensuring that high-priority services drive alerts and incident response
while low-priority or internal services remain visible but do not create unnecessary noise.

How It Works

Each service in a scope can be categorized into one of three Service Tiers:

Tier	Description
Critical: SLO Enforced	Services essential to your business or user experience. Their SLOs are actively enforced. If their SLO is violated or at risk, related Issues are marked Urgent.
Non-Critical: SLO Not Enforced	Services that are non-essential or low-impact. These services do not have an active SLO, and their Issues appear in the Issues view but are never marked urgent.
Hidden: Internal Noise	Internal or auxiliary services you do not want visible in daily operations. Issues impacting these services appear only under the Hidden tab in the Issues view.

Default Behavior

• Newly discovered services start as Uncategorized, which defaults to Critical: SLO Enforced.
• All services in this state are monitored with an active SLO until explicitly reassigned to another tier.

Assigning Service Tiers with MCP or the API

You can assign tiers through the Causely MCP server or the Causely API. Both use the following tier values:

Tier in the UI	MCP and API value
Critical: SLO Enforced	sloEnabled
Non-Critical: SLO Not Enforced	sloDisabled
Hidden: Internal Noise	hidden
Uncategorized	unassigned

Tiers are not limited to services. Setting sloEnabled on an HTTP path, RPC method, or queue enables SLO tracking for that entity. See SLO Targets and Burn Rates for how to tune those SLOs.

Using the Causely MCP Server

The following MCP tools manage tiers. They require the Developer or Administrator role.

Tool	Use
get_service_tier	Check the tier assigned to a service or other entity
set_service_tier	Assign a tier, or enable SLO tracking on an HTTP path, RPC method, or queue
clear_service_tier	Remove the tier assignment and revert to the default

For example, you can ask your agent:

Mark the internal-metrics-exporter service as hidden.

note

Clearing the tier on an HTTP path, RPC method, or queue also removes its SLO. To keep the tier record but stop SLO tracking, set the tier to sloDisabled instead.

Using the Causely API

Tiers are stored as entity configurations of type EntityTier. Use the createEntityConfigs mutation to assign a tier and deleteEntityConfig to remove it. See Setting SLOs on Paths and Methods for complete examples.

Assigning Service Tiers in the UI

1. Navigate to Settings → Service Tiers.
2. Search or filter for the services you want to prioritize. Note that the available services depend on the currently selected scope.
3. Select one or more services.
4. Use the Tier Assignment panel to set a tier:
   • Critical: SLO Enforced
   • Non-Critical: SLO Not Enforced
   • Hidden: Internal Noise

You can assign tiers individually or in bulk across pages.

Diagnosis Visibility

Tier assignment affects how Diagnoses appear in Root Causes:

• Critical: Appears in Active. Marked Urgent if the SLO is violated or at risk.
• Non-Critical: Appears in Active but never marked urgent.
• Hidden: Appears only in the Hidden tab, not in Active or Historical.

Example Use Cases

• Critical: Core APIs, payments, authentication, customer-facing services.
• Non-Critical: Internal dashboards, staging workloads, low-traffic utilities.
• Hidden: Background jobs, test services, deprecated components.