What you can expect from us

A note on who's behind this

SupportStudioK12 is built and run by a small team of three K12 practitioners in Tennessee — a tech director, a network administrator, and a technician — as a side project to give small districts a help desk that actually fits how they work. That changes what you should expect from this SLA in a few important ways:

• You get direct access. When something breaks, you're talking to the people who built the system, not a tier-one support queue.
• We don't pretend to be a 24/7 NOC. Our support hours and response times reflect reality — three people with day jobs and families, not a staffed on-call rotation.
• We err on the side of over-communicating. If we're going to miss an SLA target, you'll hear it from us first. The status page and your admin's inbox are the two channels we use.
• Credits are automatic. You don't have to request anything or prove impact — if we miss SLA, we apply a subscription extension and email you.

This document is a real commitment, not a sales prop. Every number in it is one we believe we can hit — and if we can't, we'll rewrite the SLA rather than miss it repeatedly.

Uptime

We measure uptime using a self-hosted Uptime Kuma monitor running on a separate machine from the application itself, with checks every 60 seconds against our health endpoint and the main district-facing URLs. The authoritative record is our public status page at uptime.supportstudiok12.com/status/public, which shows rolling 90-day history and live check results. You can also ask for a monthly uptime report anytime by emailing [email protected].

We maintain a separate internal status page at /status for per-tenant announcements (planned maintenance, known issues specific to a district).

If we miss the target

If we fall below 99.5% in a calendar month, we'll automatically extend your subscription by one month at no charge. You don't need to request it or file anything — we'll email you within 5 business days of month-end with the details and you'll see it reflected on your next Stripe invoice. Maximum of 2 months of extensions per calendar year.

What uptime does NOT include

• Scheduled maintenance — announced at least 7 days in advance on our status page and by email to admins. Always held overnight (11pm–5am US Eastern) and avoided during the first week of school and known standardized testing windows.
• Upstream outages from infrastructure we depend on — Hetzner, Cloudflare, Stripe, Microsoft Graph, Google Workspace, Twilio, OpenAI. When these go down, we are also down, and there's nothing we can do to bring them back. We'll post status updates and correlate with their official status pages.
• DDoS or other security attacks requiring emergency mitigation.
• Force majeure — natural disasters, war, government shutdowns, major internet-routing incidents.
• Issues caused by the district — credential sharing, misconfigured SSO, bad automation rules written by tenant admins, etc. We'll always help you fix these, but they don't count against uptime.

Support hours & response times

Outside those hours, email and the in-app feedback form are still monitored, but response times reset to the next business day. For a true middle-of-the-night emergency (like a suspected security breach), the in-app feedback form pages us faster than email will.

How severity works

When you report an issue, we classify it by how much it's impacting your district. All response and resolution times below are measured in business hours within our support window.

We classify the initial severity; if you disagree, email us and we'll discuss. Severity can be reclassified up or down as we learn more.

Keeping you informed

Status page (/status)

This is the authoritative source for real-time service status. Any incident at Severity 1 or 2 will be posted here within 30 minutes of detection, with updates at least every 4 hours until resolved. We also post scheduled maintenance windows here 7+ days ahead.

Scheduled maintenance

When we need to take the service down for upgrades or migrations:

• At least 7 days advance notice on the status page and by email to each tenant's admins.
• Windows are always 11pm–5am US Eastern.
• We avoid the first 2 weeks of the school year (roughly August 15 – September 15 in most districts) and known state/federal testing windows.
• If maintenance needs to go long, we post updates every 30 minutes.

Incident communications

During an active Severity 1 or 2 incident, you'll see:

• A banner on the status page within 30 minutes of detection, updated at least every 4 hours
• Email to tenant admins if the incident lasts longer than 30 minutes
• A post-mortem email within 7 business days of resolution for any Severity 1

How to reach us

What we promise not to do

Some commitments are easier to make by naming what we won't do. These are the things that would let us hit better SLA numbers on paper but that we think are the wrong way to run a service:

• We won't narrow the "uptime" definition to exclude the features you actually use. Our 99.5% applies to the core workflow — if login, ticketing, or notifications are broken for you, we're down.
• We won't require a support request for credits. If we miss the target, credits apply automatically. Most vendors make you file a claim within 15 business days; we think that's a quiet way to avoid paying out.
• We won't move the goalposts. If we find ourselves missing SLA repeatedly, we'll either fix the underlying problem or publish a lower commitment — we won't just re-measure until the old number works again.
• We won't hide behind subprocessor SLAs. If Hetzner or Cloudflare goes down and takes us with it, that's our problem to communicate about — not yours to track across five other status pages.

Versioning & changes

This SLA can be changed, but not quietly. If we update it:

• Material changes (response times, uptime target, credit policy) are announced to tenant admins at least 30 days before the effective date, with a redline.
• Clarifications and typo fixes are applied in-place and noted at the bottom of this page.
• Your current DPA pins the SLA version in effect at signing time — if we weaken the SLA, you can hold us to the old version through your renewal.

Version: 1.0 · Effective: April 19, 2026 · Last updated: April 19, 2026