Service Level Agreement (SLA) — draft

This page describes the service levels SIAX intends to commit to. It is published as a draft: the levels, credit tiers and definitions below must be approved by the company and incorporated into the customer agreement before they become binding. Until then, the text describes how we work — it isn't a term you can invoke.

We're publishing the draft instead of waiting until everything is finalized, because an SLA nobody has had the chance to read and object to rarely turns out well. If you need a signed SLA before you move in, we'll go through the points one by one and sign what actually applies to your setup.

The SLA covers paid subscriptions. Free tiers, open trial periods and features marked beta are not covered — nor are the ten free checks in Monitoring.

SIAX does not have ISO 27001, SOC 2 or PCI-DSS. An SLA is an availability commitment, not a certification, and the two shouldn't be conflated. What we can show instead is GDPR compliance, that data is kept in the EU, and that the stack is open source and therefore auditable.

• Open question: should the credit cap be set at 50% of the monthly fee or higher?
• Open question: should degraded response time without an outage count as downtime, and if so, at what threshold?
• Open question: should after-hours on-call be offered as an add-on, and at what price?
• Open question: where is measurement data published so you can verify our figures without asking us?
• Open question: what levels should apply to Backup, Domain, Monitoring and the AI gateway, which have no commitment in this draft?

The commitment applies per service instance and calendar month. If you have three apps and two databases, five separate commitments are measured, and a missed level on one instance doesn't affect the others.

App Hosting, Managed Postgres, Object Storage, Email, and Git and CI are at 99.9%. They run on shared, redundant infrastructure where we can move a workload to another node without physical intervention.

VPS and dedicated server are at 99.5%. The reason is hardware: if a disk, a power supply or a motherboard fails, a physical replacement is needed in the data hall, and that takes hours rather than minutes. We'd rather promise 99.5% and keep it than promise 99.9% that assumes no hardware ever fails.

Backup, Domain, Monitoring and the AI gateway have no uptime commitment in this draft. For domains, operation itself is governed by the registry, not by us. For the AI gateway, we can reasonably commit to the gateway's own availability but not to the underlying model providers' — how that should be worded is one of the points still outstanding.

• App Hosting (from 99 kr/mo): 99.9% — about 43 minutes of downtime in a 30-day month
• Managed Postgres (from 89 kr/mo): 99.9% on connection and query response
• Object Storage (from 25 kr/100 GB): 99.9% on the read/write API
• Email (from 19 kr/mailbox): 99.9% on SMTP, IMAP and webmail
• Git and CI (from 199 kr for 10 users): 99.9% on the git and web service; build job queue time is not covered
• VPS (from 59 kr/mo): 99.5% — about 3 hours and 36 minutes of downtime in a 30-day month
• Dedicated server (from 890 kr/mo): 99.5%
• Backup, Domain, Monitoring and the AI gateway: no uptime commitment in the draft

Uptime is measured from external checkpoints outside our own infrastructure, at a different provider and on a different network. Measuring from inside your own data center only measures that the data center works, which is exactly the question in doubt during an outage.

A service counts as down when it fails to respond correctly to its protocol-specific check. HTTP responses in the 5xx range count as downtime; 4xx does not, since those are generally responses to malformed requests. Downtime begins at the first failed check in a series confirmed by at least two checkpoints, and ends at the first successful one.

Monthly uptime is calculated as (minutes in the month minus downtime minutes) divided by minutes in the month, rounded to two decimal places. The month is the calendar month in Swedish time (CET/CEST). Two decimal places is deliberate: rounding to one decimal place would turn 99.87% into a met commitment.

In this draft, only outages count, not degraded performance. A database that responds in five seconds instead of fifty milliseconds is effectively unusable but doesn't count as downtime. That's a real gap, and it's listed among the open points.

• Checked every 60 seconds from at least two independent external checkpoints
• App Hosting and Git: HTTP request against a known endpoint
• Postgres: connection plus a simple query
• Object Storage: write and read of a test object via the API
• Email: SMTP handshake and IMAP login
• VPS and dedicated server: network response to the instance's IP, not to your application on it
• Downtime is confirmed by two consecutive checks before the clock starts

If we miss a commitment during a calendar month, you're entitled to a credit on the fee for the affected service. The credit is calculated on that service's monthly fee, not on the whole invoice, and only one tier applies per service per month — the highest one triggered.

For VPS and dedicated server, where the commitment is 99.5%, the first tier is triggered when uptime falls below 99.5%. The lower tiers are the same across all services. That construction is a design choice in the draft and one of the things that should be reviewed before the agreement is finalized.

In the draft, the credit is the only remedy for missed uptime. That's industry standard, but it's also a limitation worth stating plainly: the credit is rarely anywhere near what an outage actually costs you. If you run a business where an hour of downtime costs more than a month's fee, the right answer is redundancy across two locations, not a bigger SLA. We'd rather have that conversation than inflate the credit percentage.

• Below the commitment but at least 99.0%: 10% of the monthly fee
• Below 99.0% but at least 95.0%: 25% of the monthly fee
• Below 95.0%: 50% of the monthly fee
• Only the highest triggered tier applies per service per month
• Credits for multiple services in the same month are summed, but never exceed 50% of the fee for a single service
• Credit is issued as an invoice deduction, not a cash refund

An SLA that doesn't spell out its exceptions isn't honest. The following periods are not counted toward downtime.

The two exceptions that most often spark a discussion are the customer's own code and denial-of-service attacks against the customer's application. If your app crashes from running out of memory, a certificate expires, or a deploy takes the service down, the platform is working — and the platform is what we commit to. In the event of a DDoS against your application, we do what we can to mitigate, but we don't promise to succeed.

Emergency maintenance we don't have time to announce 72 hours in advance is not exempt. If we have to patch a critical security hole on short notice and it causes an outage, it counts as downtime. Calling emergency fixes "planned maintenance" is exactly the kind of loophole that makes SLAs worthless.

• Planned maintenance announced at least 72 hours in advance and carried out within the announced window
• Force majeure: natural events, war, labor disputes, major power or transit outages, government decisions
• Faults in the customer's own code, configuration, container image, resource allocation, or expired certificates
• Denial-of-service attacks or traffic spikes directed at the customer's own application
• Dependencies the customer has chosen outside our control: external APIs, DNS with another operator, third-party services
• Suspension due to unpaid invoices or breach of the terms of use
• Actions carried out at the customer's request, such as a restore or migration
• Free tiers, trial periods, and beta features

A credit must be requested within 30 days of the end of the month in which the outage occurred. The request is made via support and must include the service, instance name, date and time range, and what you observed. If you have your own measurement data or logs, that helps, but it isn't required — we always cross-check against our own measurements.

We respond to a credit request within ten business days. An approved credit is deducted from the next invoice. If the subscription ends before the credit has been used, it's settled in cash on the final invoice.

The credit isn't applied automatically. We'd rather have automatic crediting, but that requires measurement per customer instance to be fully automated and reconciled against billing. Until that's in place, a credit is something you request, and we'd rather say that plainly than let you think the system handles it for you.

• Deadline: 30 days from the end of the month
• Channel: a support ticket with SIAX
• Include: service, instance, date and time, and what you observed
• Our response time: within ten business days
• Payout: deducted from the next invoice, cash settlement on the final invoice

Response time is the time to the first qualified reply from a person who can act on the case, not the time to a resolved issue. No provider can promise a resolution time for a bug it hasn't seen yet, and an SLA that does is counting on you not reading it.

Response times apply during business hours, Monday to Friday 09:00–17:00 Swedish time, excluding Swedish public holidays. A ticket registered outside business hours has its clock start when the next business day begins. We don't currently offer round-the-clock on-call under the standard agreement, and that should be stated here rather than discovered at three in the morning. If your business needs after-hours response, that's an add-on to discuss separately.

Severity is set by you when you file the ticket. We may adjust it if the assessment is clearly wrong, and if so, we explain why.

• Critical: production service is unavailable or data is at risk of loss, no known workaround — response within 2 hours
• High: a significant function is degraded but operations can continue with a workaround — response within 8 hours
• Normal: questions, configuration, planning, change requests — response within 1 business day
• Business hours: Monday–Friday 09:00–17:00 CET/CEST, excluding Swedish public holidays
• The support ticket is what starts the clock, even though chat is sometimes faster

Maintenance that may cause an outage is scheduled in the Tuesday-to-Thursday 23:00–05:00 Swedish time window and announced at least 72 hours in advance to the account's technical contacts and in the status channel. The notice states which service is affected, what's being done, and the maximum outage we expect.

Most maintenance on shared infrastructure happens on a rolling basis without any outage: we move workloads to other nodes, update, and move them back. On VPS and dedicated server that isn't always possible, since a kernel update or a hardware swap requires a reboot. There, expect a handful of announced restarts per year.

We can rarely move a maintenance window for a single customer, but we can generally control the order in which nodes are taken. If you have a period where an outage would be especially inconvenient — year-end closing, a campaign, peak season — let us know in advance and we'll plan around it if possible. Emergency security maintenance may need to happen on shorter notice, and if it causes an outage it counts as downtime under the section above.

• Window: Tuesday–Thursday 23:00–05:00 CET/CEST
• Notice: at least 72 hours in advance, to technical contacts and the status channel
• Frequency: expect a handful of windows per quarter, most without any outage
• Rolling updates on shared infrastructure, announced restarts on VPS and dedicated server
• Emergency security maintenance may occur on shorter notice and is not exempt from the downtime calculation