Main: Service Levels

Updated

Main: Service Levels

Overview

Use this page to understand how the Service Levels module turns monitoring data into formal, reportable targets. The Service Levels overview is the informational front door for the service level area, sitting in the Main section of the navigation menu alongside the other module overviews. It draws the moving parts as one diagram, sequences the work as a lifecycle, and links into the pages where each piece is configured.

Service Levels answers the question "are we meeting what we promised?". Every other monitoring surface tells you what happened; Service Levels tells you whether what happened was acceptable, against a target you defined in advance. You declare services, attach Service Level Objectives such as an availability percentage or a maximum response time, and the platform evaluates them continuously against telemetry already flowing from Uptime, End-to-End Monitoring, and Load Testing. The business value is a defensible compliance record: error budget consumption you can show a stakeholder, breach diagnostics you can investigate, and a public status page you can point customers at without giving them a login.

This page changes nothing and requires no configuration to open. The capability cards are navigation into the Service Levels pages, and those pages keep their own licence and role gates.

Main: Service Levels, full page

Key concepts

  • Service - The named thing whose reliability you are tracking. Services are declared once and everything else in the module hangs off them. (related: Configuration: Service Levels: Services)
  • Service Level Objective (SLO) - A measurable reliability target, for example 99.9% availability or a maximum response-time threshold, evaluated continuously against a chosen data source. (related: Configuration: Service Levels: Objectives)
  • Mapping - The join between an objective and a service. Mappings are what make an abstract target concrete, by saying which service a given objective actually measures. (related: Configuration: Service Levels: Mappings)
  • Data source - Where the measurements come from. Service Levels draws on Uptime, End-to-End Monitoring, and Load Testing, so an objective is evaluated against telemetry the platform is already collecting rather than a separate feed.
  • Error budget - The permitted amount of failure implied by an objective. Consuming it too quickly is what burn-rate alert rules detect. (related: Service Levels: Operations)
  • Snapshot storage - The SQL Server or PostgreSQL store that holds evaluated measurements. Without it, the module has nowhere to record compliance history. (related: Configuration: Service Levels: Storage)

When to use it

  • When you have monitoring in place and now need to report compliance against agreed targets.
  • When you need to explain to a stakeholder what an SLO, an error budget, and a breach mean in this platform.
  • When you are setting the module up and want the prerequisite chain, especially the storage requirement, in one view.
  • When compliance figures look wrong and you want to re-check how services, objectives, and mappings connect.
  • When you want to publish availability externally and need to know where status pages sit in the workflow.
  • When you want a launch point into the Service Levels dashboard, health, objectives, violations, operations, status pages, or access control.

Before you begin

  • No prerequisites for opening this page. It is informational and ungated.
  • Using the module requires the Service Levels licence module (LG058). Without it, the Service Levels pages show an activation card instead of the feature. Check your entitlement on Infrastructure: Licensing.
  • A snapshot storage datasource, SQL Server or PostgreSQL, must be provisioned on Configuration: Service Levels: Storage. This is the prerequisite most often missed: without it, health and violations have nothing to query.
  • At least one service must exist on Configuration: Service Levels: Services, with objectives attached and mapped to it.
  • The evaluation scheduler must have run at least one cycle before a window contains data.
  • The module depends on upstream telemetry. If Uptime, End-to-End Monitoring, or Load Testing is not producing data for a service, its objectives report NoData rather than compliance.

Steps

Step 1

Open Service Levels in the Main section of the left navigation menu.

Expected result: The overview page opens immediately, with the architecture hero at the top. It renders on an appliance with no services or objectives configured yet.

Step 2

Read the architecture hero.

The diagram shows the three upstream sources (Uptime, End-to-End Monitoring, and Load Testing) feeding measurements into the service level evaluation, the mappings that join objectives to services, and the snapshot store that records the results. Downstream it shows the consumers: health and compliance views, violation diagnostics, burn-rate alerts, and externally published status pages.

Quantities drawn inside the diagram are illustrative and prefixed e.g.; they do not read your configuration.

Main: Service Levels, architecture hero

Main: Service Levels, lifecycle strip

Step 3

Follow the lifecycle strip.

The strip lays Service Levels out as six ordered steps. The underlying chain, as documented across the Service Levels pages, is:

  1. Provision storage. Set up the SQL Server or PostgreSQL snapshot store on Configuration: Service Levels: Storage.
  2. Declare services. Name what you are tracking on Configuration: Service Levels: Services.
  3. Define objectives. Set the targets and thresholds on Configuration: Service Levels: Objectives.
  4. Map objectives to services. Join the two on Configuration: Service Levels: Mappings, and set business hours and exclusions on Policies so out-of-hours downtime is not counted against you.
  5. Let it evaluate. Configure the evaluation cadence on Configuration: Service Levels: Scheduler.
  6. Read and publish. Track compliance on Service Levels: Health, investigate breaches on Violations, and publish externally on Status pages.

The page's lifecycle strip, From promise to proof, in six steps, reads: 1 Define (services that matter), 2 Map (objectives to services), 3 Set (objectives + windows), 4 Evaluate (on the scheduler), 5 Watch (budgets burn down), 6 Publish (status pages). The numbered list above expands those labels (verified).

Step 4

Use the capability cards to enter the module.

Each card names one thing Service Levels does and links to the page where you do it. Selecting a card is read-only navigation; no objective is evaluated and no configuration is changed from this page.

Main: Service Levels, capability cards

Step 5

Note that this page has no pulse chip row.

Like the SessionSight overview, Service Levels ships without live counters, deliberately, rather than showing numbers that could not be sourced reliably. Open Service Levels: Dashboard for real readiness and coverage figures, including whether the snapshot store is ready.

Next steps

Verify the result

The page is working correctly when the architecture hero renders as a diagram, the lifecycle strip shows its steps, and the capability cards navigate into the Service Levels pages. Nothing is saved here, so there is no state to confirm. The absence of a live counter row on this page is by design, not a fault.

Troubleshooting

  • Symptom: A capability card opens a page showing an activation card with Activate License and Learn More. Fix: Service Levels (LG058) is not licensed on this appliance. Check Infrastructure: Licensing. This overview page is ungated by design and describes the module regardless.
  • Symptom: The lifecycle mentions Services, Objectives, Mappings, Policies, Scheduler, or Storage, none of which are in your navigation menu. Fix: CONFIGURATION: SERVICE LEVELS is an Expert-mode section; switch the sidebar footer toggle to Expert.
  • Symptom: Health and Violations show nothing at all. Fix: Confirm the snapshot storage datasource is provisioned on Configuration: Service Levels: Storage and that the scheduler has completed at least one evaluation cycle within the window you are querying.
  • Symptom: Objectives report NoData rather than a compliance figure. Fix: NoData means no measurements arrived, not that the target was missed. Check that the upstream source (Uptime, End-to-End Monitoring, or Load Testing) is producing data for that service, and that a mapping joins the objective to it.
  • Symptom: Downtime during a planned maintenance window is counted against compliance. Fix: Define business hours and exclusions on Configuration: Service Levels: Policies.
  • Symptom: An objective exists but appears on no service. Fix: An objective without a mapping measures nothing. Create the join on Configuration: Service Levels: Mappings.
Was this article helpful?
0 out of 0 found this helpful