Glossary

Common terms used in the SLOzy platform and SLO management.

A

Availability

The percentage of time a service is operational and accessible. Often measured as uptime divided by total time.

B

Burn Rate

The rate at which the error budget is being consumed, relative to the SLO target period. A burn rate of 1.0 means the error budget will be exactly exhausted at the end of the window. A burn rate of 2.0 means it will be exhausted halfway through.

Burn Rate = Budget Consumed / (Elapsed Time / Total Window)

Budget (Error Budget)

See Error Budget.

C

Composite SLO

An SLO that combines multiple underlying service-level indicators (SLIs) into a single target. For example, a composite SLO might require both 99.9% availability and < 100ms latency.

D

Dashboard

A visual display of SLO health, error budget consumption, and burn rates. SLOzy provides real-time dashboards updated via WebSocket.

Data Source

A Prometheus instance configured as a metrics source for SLO calculations. Multiple data sources can be added per organization.

E

Error Budget

The maximum number of failures or downtime allowed within a time window while still meeting the SLO target.

Error Budget = (1 - SLO Target) × Time Window

For a 99.9% SLO over 30 days:

Error Budget = (1 - 0.999) × 30 days = 0.03 days ≈ 43 minutes

Error Budget Policy

Rules that define actions to take when error budget is consumed at various levels (e.g., freeze deployments at 50% consumption).

G

GitOps

A workflow where SLO configurations are managed via Git repositories. SLOzy supports GitOps by synchronizing SLO definitions from Git repositories and validating changes via pull requests.

Good Events vs. Bad Events

Events counted toward (good) or against (bad) an SLI. The ratio of good to total events determines SLO compliance.

I

Incident

An event that causes or may cause a service disruption. SLOzy can trigger alerts based on error budget burn rate to notify teams before an SLO is violated.

M

Multi-Window, Multi-Burn-Rate (MWMBR)

An alerting strategy that uses multiple time windows and burn rate thresholds to detect SLO violations early while avoiding false positives.

R

Remediation

Actions taken to prevent or recover from SLO violations. This may include rollbacks, scaling, or deploying fixes.

Rollup

Aggregation of SLIs from multiple services or components into a higher-level SLO.

S

SLA (Service Level Agreement)

A contractual commitment between a service provider and a customer, specifying expected reliability levels and consequences for violations.

SLI (Service Level Indicator)

A measurable metric used to evaluate service reliability (e.g., request latency, error rate, throughput). SLIs are the raw data points that feed into SLO calculations.

SLO (Service Level Objective)

A target reliability value expressed as a percentage over a defined time window. For example, "99.9% of requests complete successfully over a 30-day rolling window."

T

Time Window

The period over which SLO compliance is measured. Common windows include 7 days, 30 days, or a rolling window. SLOzy supports configurable time windows per SLO.

Time Window (Sliding)

A continuously updated window that always represents the most recent N days/weeks. For example, a 30-day sliding window always includes the last 30 days of data.

W

WebSocket

A protocol used by SLOzy for real-time dashboard updates. The WebSocket hub (internal/websocket/handler.go) pushes SLO metric changes to connected clients without polling.

Window

See Time Window.