SLA & availability

Availability metrics

The service detail page and the availability table show several metrics. Each column header has an info button that shows the definition in a popover, on the public page in the configured language (AVAILABILITY_METRIC_GLOSSARY in lib/domain/availability.ts).

Metric	Definition
Overall Availability	Share of time the service was fully operational. Every disruption counts, including planned maintenance.
Excl. Maintenance	As above, but maintenance windows are excluded from the calculation
Service Availability	Share of time without major or partial outage (majorPartial). On the service detail page, this is the value under the 90-day bar.
SLA Availability	Like service availability, but only outages inside the assigned SLA schedule count. Maintenance is not subtracted, unless the plan has the option "Ignore Outages during maintenances". Without a plan, it equals service availability.
SLA Target	The target configured for the period (month, quarter or year). The comparison (✓ / ✗) uses SLA availability. Without a target, or without SLA time in the period, it shows "—".

The table shows eight periods: this week, this month, last month, this quarter, last quarter, the last 90 days, year to date, and one year (the last 365 days).

SLA plans and schedules

An SLA plan (sla_plans) defines when the service must be available. It contains one time window per weekday (sla_plan_entries), with start and end in minutes. from == to means closed on that day. At least one weekday must be open.

• Each component is assigned to at most one plan (components.sla_plan_id).
• No plan = 7×24. Every hour of every day counts.
• An outage counts toward SLA availability only if it overlaps the schedule. For example, an outage at night does not reduce the SLA availability of a plan that is only active from 08:00 to 18:00.
• With the option Ignore Outages during maintenances (sla_plans.ignore_outages_during_maintenance, default: off), outages inside maintenance windows do not count toward SLA availability. This applies to the table and the bars. The service detail page shows a note about it.

Time zones follow settings.timezone. Final report exports use the time zone stored in the snapshot (see below).

Holidays

A holiday list (holiday_lists) contains dates with month and day. A date with no year recurs every year (input format D.M., for example 1.1.). A date with a year applies only once (input format D.M.YYYY). Duplicate dates in a list are prevented by a unique constraint.

A plan can reference one holiday list. On a holiday, the holiday window replaces the weekday window. If the holiday window is closed (the default, 0/0), the service has no SLA time on that day. Only exactly 0/0 counts as closed. Any other window with start ≥ end is rejected with "Holiday window: from must be before to." Without a list, every day counts as its weekday. The same rules apply to the service detail page, the bars, the SLA reports and the incident metrics.

A list that is used by a plan cannot be deleted.

SLA relevance

Each component has a flag SLA relevant (components.sla_relevant, default: yes). Services marked as not relevant are excluded from SLA reports. They still appear in the SLA administration and can still be assigned plans and targets. Setting a service to "not relevant" removes it from the open confirmation lists of reports that are still in progress. Frozen snapshots are not changed. If it becomes relevant again, confirmations only apply from the next report start.

Targets and bars

Each component has optional targets for month, quarter and year (percentages). The public bars use them:

• Monthly bar on the service detail page: one tick per calendar month from January of the previous year. Green at 100 %, red below the monthly target, linear transition in between.
• Quarterly bar: from Q1 of the previous year to the current quarter, colored against the quarterly target. The current quarter is aligned to months and can be 1 to 3 months wide.
• 90-day bar: the percentage label is colored against the quarterly target when one is set. Without a target, it stays neutral.

Without a target, the monthly and quarterly bars are still colored, with 0 % as the lower bound: red at 0 %, green at 100 %. Without an assigned plan, 7×24 is used. A section only stays grey if the assigned plan has no SLA time in that period.

Incident SLA metrics

In addition to availability, SLAtus measures per service how quickly incidents are responded to and resolved. This is configured per component in the SLA administration:

• Incident SLA level (incident_sla_level): which impacts count, for example only critical, or critical + major.
• Maximum response time and maximum resolution time in hours.
• Allowed misses per month, quarter and year, separately for response and resolution.

Times are measured from the next start of SLA time (nextScheduleStart), so an incident outside the schedule only starts the clock with the next window. The results appear in the SLA reports (computeIncidentSlaMetrics).

SLA reports

Reports (sla_reports, page /admin/sla-reports) exist for months, quarters and years.

open → in_progress → confirmed → completed

• Monthly reports require confirmation. When the report starts, every degraded_performance, partial_outage or major_outage window of an SLA-relevant service that starts or ends in the month appears as a row in sla_report_outages. Each row must be confirmed by a user with the right permission. When all rows are confirmed, the report is promoted to confirmed. At this point the complete report data is frozen into confirmed_snapshot.
• Starting a report sends sla_report_started to the service managers and to the owners of services with outages to confirm.
• Generate turns a confirmed report into completed. This is only possible once all incidents of the period are reviewed (reviewed or closed).
• Quarterly and yearly reports have no confirmation step. A quarterly report is only possible once all three monthly reports are completed, a yearly report once all four quarterly reports are completed.

Info

Changing a plan, a target or a holiday list after confirmation does not change the numbers of a confirmed or completed report. This is intentional, so that published SLA figures stay stable.

Export (PDF and Excel)

PDF and Excel files are generated on every request. Nothing is stored on disk. The export language follows settings.language; decimal separator, decimal places and date format are applied at render time.

Report status	Source	Marked as
completed, confirmed with snapshot	frozen snapshot (confirmed_snapshot, otherwise report_data)	final
open, in_progress, confirmed without snapshot	calculated live	draft, watermark "DRAFT" or "ENTWURF"
Ad-hoc export	calculated live, not stored	preliminary, watermark "PRELIMINARY" or "VORLÄUFIG"

• PDF (lib/pdf/sla-report.ts): title page, table of contents, overview, service details, and an appendix with glossary and calculation basics. Long content continues on following pages. Content is only shortened visibly with "...": table cells over 40 lines, and table-of-contents entries and headers and footers to their width. Characters outside the WinAnsi character set are printed as "?".
• Excel (lib/export/sla-report-xlsx.ts): sheets cover, overview, outages, incidents, maintenance and glossary. Cells over 32,000 characters are shortened with "...".
• Per service: /admin/sla-reports/[id]/pdf and /admin/sla-reports/[id]/xlsx accept an optional ?service=<id> and narrow the report to one service.
• Ad hoc: /admin/sla-reports/adhoc exports one SLA-relevant service for a month, a quarter or a year, without creating a report. A running period is measured up to now; a period that has not started yet is rejected.
• Time zone: final exports calculate in the time zone that was stored in the snapshot when it was frozen (GeneratedReport.timeZone). Older snapshots without this field use the current settings.timezone.
• Errors: a report ID that is not a UUID or does not exist returns 404. Rejected ad-hoc requests show a simple error page with a link back to the report list.
• Access is granted to all roles in ROLES_CAN_VIEW_SLA_REPORTS: admin, service manager, SLA manager and service owner.

Where the numbers come from

Calculation logic lives in pure functions: measureSlaWindow and windowForDay in lib/domain/sla.ts, nextScheduleStart for incident metrics, and buildSlaReportDataForPeriod for reports. Their inputs are status windows from the status model and the schedule configuration. Stored snapshots are always read through parseGeneratedReportJson (lib/domain/sla-report.ts), which fills fields missing from older snapshots with neutral values.