# StatOSS, in full

StatOSS (https://statoss.com) is a hosted uptime checker with public status pages. It is run by enkelt.design, Denmark. Support: support@statoss.com, or the form and chat at https://statoss.com/support.

It is the hosted, multi-user version of statoss-standalone (https://github.com/kroqdotdev/statoss-standalone), an MIT licensed project that runs the same checker and the same page in one container against your own SMTP server. The standalone version has no limit on pages or monitors and is free. StatOSS adds accounts, a dashboard, hosting, regions, and billing.

## Checks

- Each status page has monitors. A monitor is an HTTP request (any method, with optional headers, body, expected status and keyword), a TCP port, a DNS lookup, a ping, a TLS certificate, a domain's expiry date, a heartbeat your job pings, or a component set by hand. HTTP, TCP, DNS and ping run once a minute (every 5 minutes on Free) with a ten-second timeout; certificates hourly; domain expiry every 6 hours. Certificate and domain monitors show the date they expire.
- The checks come from four regions: Europe (Aarhus and Copenhagen in Denmark, Falkenstein in Germany), North America (Ashburn, USA), Asia (Singapore) and Oceania (Sydney, Australia). On Hobby and Pro the regions take turns, one check a run, and the places in a region take turns inside it.
- Hobby and Pro can add check locations under Settings, Check locations: London, Paris, San Jose, Toronto and São Paulo at $4 a month, Johannesburg and Tokyo at $8. Pro includes $4 of them. A fixed IP on an added location is $4 a month; it is shared by the accounts that added that location, so a site should let it in together with a secret header.
- A failed check is looked at again in its region (by another location, or by the same one when it is the only one there) before it counts, and every region checks at once. A monitor can be pinned to one region, for a site that lets only a fixed IP in.
- A page picks the regions whose readings count toward its response times and slow alerts, and the regions that count toward its uptime; a monitor may pick its own. Readings from other regions count toward up and down only. A monitor can also have a slow threshold of its own in some regions: a reading from one is judged against its number instead.
- A check succeeds when the response arrives in time with a 2xx status, or with the exact status the monitor expects when one is set (a monitor can expect a redirect or a 401, for example). Anything else is a failure: a timeout, a connection error, a TLS error, or an unexpected status.
- Every result is stored: the time, the location, whether it succeeded, the response time and where it went (lookup, connection, TLS handshake, first byte), the status code or the error, and the address reached. Every result is kept for 14 days (7 on Free). Hourly totals behind the longer views are kept for 7 days on Free, 90 on Hobby and a year on Pro.
- Monitors can be imported under Monitors, Import from another service: UptimeRobot (the API's JSON or the CSV export), Better Stack (API JSON), Statuspage components and incidents (API JSON), or any CSV with a URL column. Statuspage incidents come along as history. Nothing is removed from the other service.
- The dashboard has a Test URL button that runs one check right away before a monitor is saved, and a Check now button on saved monitors. Targets on private or internal addresses are refused.

## The page

- Every page is public from the moment it is created, at `https://<slug>.statoss.com` and at `https://statoss.com/s/<slug>`. On Free the slug is assigned: the page name as a label plus four random characters, for example northwind-k3f9. Hobby and Pro choose their own slug (3 or more characters, lowercase letters, digits and hyphens).
- On Pro, a page can also be served at a hostname the owner controls, such as status.example.com. The owner adds two DNS records: a CNAME to edge.statoss.com (A and AAAA records for a bare domain), and a TXT record named _statoss under the hostname (_statoss.status for status.example.com) with the value statoss-verify= and the page's token, which shows the domain is the page's. StatOSS checks both, says which one is still missing, and the certificate is issued and renewed by StatOSS on the first visit. The TXT record is what ties the domain to the page: DNS pointing at StatOSS alone never does.
- On Pro, a page can be private: only the people and email domains the owner allows see it. A visitor enters their address, gets a link that works once for 15 minutes, and stays signed in on that browser for 30 days. A page can also have a password.
- The page shows one strip per monitor. The strip is a histogram of the chosen range (a day by default, also 7 days, 90 days and a year; a plan offers only the ranges its history covers). Each bar's height is the median response time. On the 24-hour range a bar is the median of the eleven readings around it in its region, and above the strip are the median and the figure 95% of checks came in under. A region's slower places are scaled to its fastest place's level, compared hour by hour.
- Amber marks a timeout. Red marks any other failure. Consecutive failed checks are grouped into one entry under the strip with the start time, the duration and the reason. With several regions there is a lane per region under each strip, a line per region under the headline, and response time by region under each monitor.
- Bars for the time before the page had history are shaded.
- Incidents have their own pages, and a history page lists past ones. Maintenance can be planned once or to repeat every week or month; each window is announced like one planned by hand, and every page has a calendar feed of its maintenance at /maintenance.ics.
- On Pro, visitors can subscribe by email, Slack, Discord, Microsoft Teams or a webhook. Subscribers can be imported from a CSV with an email column (Statuspage, Instatus and Better Stack export one) or a list of addresses, and downloaded as CSV. Every subscriber email has a link to pick the monitors it covers.
- Times on the page and in the dashboard are shown in each visitor's own time zone. The zone the owner picks (UTC by default) shows until the page has loaded. Alerts and emails are in UTC.

## Alerts

- A monitor counts as down after two failed checks in a row, and as back after one successful check; the failure is confirmed first. A single failed check sends nothing. An outage is dated from its first failed check.
- With several regions, a monitor is down while a region the page counts toward uptime is down. The alert, the page and the incident say which regions, and another alert goes out when the outage spreads to other regions or leaves some.
- Each change sends one alert: one when the monitor goes down, one when it is back, with the time, the reason and the locations that saw it. A monitor with a slow threshold goes slow after two slow responses in a row and back to normal after one fast one, each with its own alert. A page can repeat the down alert every so many minutes, by email at most every 30 minutes and 24 times in one outage. An incident a person opened or posted to that has had no update for an hour sends the owner a reminder to post one, each hour for a day at most.
- Alert destinations belong to the account (Settings, Destinations), and each page ticks the ones its alerts go to. An email address other than the account's is confirmed by a link first. Emails come from alerts@statoss.com. Outlook, Hotmail and other Microsoft mailboxes may put StatOSS email in Junk for now.
- On Hobby and Pro alerts can also post to Slack, Discord, a Microsoft Teams channel (through a Workflows URL) and Telegram (through your own bot), page through PagerDuty or Opsgenie (opened on down, closed on recovery), push to Pushover (down alerts at high priority, or repeating until acknowledged) or ntfy, and call a signed webhook.

## On-call

- On Hobby and Pro. Free has none. Hobby is for one person with 3 alert sources; Pro is for the whole team with 50, and adds escalation policies, schedules, each person's own notifications and the import.
- A source is one integration key on a status page. Anything that sends to PagerDuty's Events API (v2, v1 and change events), Opsgenie's Alert API (create, acknowledge, close and notes, by id, tiny id or alias, request status, heartbeat pings) or Sentry's webhooks sends to https://api.statoss.com instead, at the same paths, with the source's key. Change events become deploy markers. A source takes 120 events a minute.
- An alert is open from its first trigger until it is resolved; later triggers with the same key count onto it. A monitor going down opens an alert too, and its recovery resolves it. Alerts go to the page's destinations, or to the destinations and people a source picks, and repeat until someone acknowledges them (every 5 minutes by default; email at most every 30 minutes and 24 times an alert).
- Acknowledge or resolve from the dashboard, the signed links in the alert email, Pushover's emergency notifications, the Acknowledge and Resolve buttons in a Slack channel added with Connect Slack, the API (/api/v1/pages/{pageId}/alerts), the MCP tools list_alerts, get_alert, acknowledge_alert, resolve_alert and snooze_alert, or the sender's own calls. An acknowledgement lasts 4 hours by default (set per page, or until resolved); then a still-open alert pages again. Snoozing holds an alert for up to a week without saying anyone has it.
- A source can group alerts that arrive within 2 to 30 minutes of its first open one: grouped alerts page nobody and follow the first. While a maintenance window covers the whole page, new alerts from its sources wait for the window to end.
- Pro: escalation policies page people and schedules level by level until someone acknowledges. A schedule is rotations of people taking turns of hours, days or weeks on its time zone's clock, with limits to days and hours and overrides, and each person has a calendar feed of their shifts. Anyone can ask for cover; the first to take it gets an override. A schedule can tell a Slack channel of handoffs and keep a Slack user group to whoever is on call. On-call, Load shows pages per person by working, evening and sleeping hours, and time to acknowledge and resolve per source. Each person picks how they are reached once paged: their account email, Pushover, ntfy or Telegram, at once or after a delay.
- Past 60 new alerts from sources in an hour, a team's further warnings and infos are sent as one summary per source every 15 minutes; critical alerts and errors from sources always page one by one. The alerts an issue alert rule or a log alert rule makes are bounded by the rule: it pages 20 an hour one by one, and the rest of that hour go out as one summary per rule every 15 minutes. Nothing is dropped.
- An alert can open an incident, internal by default: off the public page, the feeds and status.json, and told to nobody until it is published.
- Pro: On-call, Import reads a PagerDuty or Opsgenie account with a read-only key, never kept, shows a preview, and makes schedules, escalation policies and sources. PagerDuty sources keep their integration keys; Opsgenie's get new ones. Phone, SMS and push contact methods, routing rules and alert history are not imported. StatOSS makes no phone calls and sends no SMS.

## Errors

- On every plan. An app is one program that sends errors, made under Apps in the dashboard. Each of its keys is a DSN, `https://<key>@ingest.statoss.com/<app number>`. Any Sentry SDK takes it where Sentry's DSN goes; so do @statoss/sdk (JavaScript and TypeScript) and the Python statoss package (over sentry-sdk). Moving from Sentry is changing the DSN. A DSN in a web page is public: a key can list the websites it allows (a request from another gets 403; a request with no Origin or Referer, as a server's, is taken), and has its own lower rate. A tunnel through the site's own server (Sentry's tunnel option) keeps the real key off the page. Docs: https://statoss.com/docs/errors and https://statoss.com/docs/send-errors#protect-a-browser-dsn.
- Free takes 5,000 errors and messages a month kept 30 days, Hobby 50,000 kept 30 days, Pro 500,000 kept 90 days, counted per calendar month in UTC across the team's apps. Past it, past a key's events a minute (1,200 at most, 10 or more where set), past an app's 1,200 a minute over all its keys and past an app's share of the team's month (half unless set, 1% to 100%, and only once the team has two apps), events are answered 429 with Retry-After, as Sentry answers. Passwords, tokens, cookies, keys and card numbers are stored as [Filtered]. Transactions, spans, sessions, replays, profiles and attachments are taken and not stored.
- Events are grouped into issues by the SDK's fingerprint, else the exception's type and in-app frames (file and function, no line numbers), else the type and value or the message's template. An issue can be resolved, resolved in the next release, archived, assigned, commented on and merged; an event after a resolve reopens it as regressed. Priority follows the level until someone sets it.
- On Hobby and Pro an app's alert rules open on-call alerts: on a new issue, a regression, an escalation, or N events in so many minutes, filtered by priority, level, environment, release, tags and category, at most once per release or every 30 minutes, hour, day or week. Each app starts with "New and regressed issues". On Free, new and regressed high-priority issues are emailed to the team's owner, up to 25 emails a month.
- Releases come from events or from sentry-cli or the StatOSS CLI (`npx @statoss/cli`), with deploys as deploy markers. Source maps uploaded by either, with a write API key, map minified JavaScript frames back to source by debug ID before events are grouped. sentry-cli takes SENTRY_URL=https://statoss.com and the API key as SENTRY_AUTH_TOKEN.
- Each app has its own levels, categories and fields: an event names them with the tags statoss.level and statoss.category, rules sort the rest, and @statoss/sdk takes the schema in code so a wrong name fails to compile. Changes reach old events at once.
- Apps, keys, issues, events, releases, source map bundles, alert rules, the schema and dashboards are in the REST API and as tools on the keyed MCP endpoint; https://statoss.com/api/v1/mcp/apps/<app> holds one app's tools.

## Logs

- An add-on to Hobby and Pro, switched on by the team's owner under Settings, Logs: $5 a month with 15 GB, then $0.25 a GB in the billing period; lines kept 30 days count twice. Billed at the period's end. Docs: https://statoss.com/docs/logs and https://statoss.com/docs/send-logs.
- Lines come with an app's key from @statoss/sdk, the Python statoss package, Sentry's SDKs, OpenTelemetry (OTLP over HTTP, or the Collector), the Vercel, Fly, Cloudflare Workers and Heroku drains, and plain JSON, to https://ingest.statoss.com. Each line has a time, a level, a body, a service, an environment, a release, a trace and span id and attributes; passwords, tokens, cookies and keys are stored as [Filtered].
- One search box (words, phrases, regular expressions, key:value, number ranges, levels, OR, and -term to leave out), the same in the dashboard, log alerts, the API and the MCP. Live tail every 2 seconds, patterns with their counts, saved views, and a line's neighbours and the issues of its trace.
- Log alerts: at least N lines, fewer than N, or none in a window of 1 to 1,440 minutes, each an on-call alert routed as issue alerts are.
- Each team has a daily cap, 1 GiB unless an owner or admin sets another; at the cap lines are refused with 429 until midnight UTC. Lines are kept 14 days, or 3, 7 or 30. An app sends up to 60,000 lines a minute.
- In the REST API (/api/v1/logs, views, log alerts), the MCP (search_logs, tail_logs, get_log, log_volume, log_facets, log_patterns) and the CLI (`npx @statoss/cli logs tail`, `logs search`).

## Accounts

- Sign up with an email address and a password (the address is confirmed by email before the account can be used), with Google, or with GitHub. Accounts created through Google or GitHub can add a password later under Settings, Security. Two-factor sign-in with an authenticator app is available to everyone, and owners and admins can require it for the team.
- One account can own several pages, within the limits of its plan. On Pro, a team: people invited by email as admins or members, 3 included and $5 a month for each one after, up to 25.
- The REST API (https://statoss.com/api/v1, OpenAPI at /api/v1/openapi.json) and the keyed MCP endpoints (/api/v1/mcp, /api/v1/mcp/read, and /api/v1/mcp/apps/<app> for one app) take API keys made under Settings, API keys, which read or write and reach every page or one. An MCP client without a key signs its person in with OAuth 2.1 instead: the person picks the team, read or read and write (owners and admins), and every app or one. Access lasts an hour and is renewed; a client unused for 30 days signs in again. Settings, Connected apps lists each client with its team, access and last use, and Revoke stops it at once. Docs: https://statoss.com/docs/agents.
- Agent registration (auth.md v0.6, https://statoss.com/auth.md, linked from every page as <link rel="auth.md">): an agent registers anonymously with a short proof of work, or with its person's email address (service_auth). An anonymous agent builds a draft with its own token: up to 3 status pages with their monitors and components, 25 in all, and 3 apps, set with PUT /api/v1/agent/draft. A draft is not public, not checked and sends no mail, and goes after 24 hours unless claimed. The person opens the agent's link, signs in or signs up with the address the agent named, picks a team they manage and types the agent's 6-digit code; the draft is then made on that team with the plan's limits, and the agent gets an access token for it through the claim grant at /oauth/token. A claimed agent acts for its person through the API and MCP, but never on API keys, the team's people or billing, and Connected apps disconnects it. The front page, https://statoss.com/docs/agents#setup-prompt and the dashboard's Help (and the new status page screen) carry a prompt to paste into a coding agent such as Claude Code, Codex or Cursor: it registers, looks through the project for URLs, scheduled jobs and logs, drafts a status page and an app, hands the person the claim link and the code, and after the claim reads the app's DSN over the API, installs the SDK and sends a test error. The dashboard's copy names the person's email address and team.
- Support can open a dashboard read-only for 30 minutes to help; each time is listed under Settings, Security with the reason.
- Delete a page from its settings page. Deleting a page removes its monitors and history.
- Settings, Your data downloads everything the account holds as one JSON file (account, pages with settings, monitors, incidents, templates, subscribers, deploy markers, every stored check and hourly rollup; alert destinations, secrets and the page password left out) and deletes the account after the email address is typed to confirm. Deleting the account cancels any subscription at once and removes every page.

## Plans and billing

- Free, hosted: 1 status page, 1 monitor, checks every 5 minutes, 7 days of history, down and recovery emails, 5,000 errors a month kept 30 days. No card needed. This is what an account has without a subscription.
- Free, self-hosted: run statoss-standalone yourself.
- Hobby, $4 a month: 1 status page, 10 monitors, checks every minute from every region in turn with a response-time line per location and a choice of which regions count toward response time, 90 days of history, an address of your choice, email plus Slack, Discord, Microsoft Teams, Telegram, PagerDuty, Opsgenie, Pushover, ntfy and webhook alerts, on-call for one person (3 alert sources, repeats until acknowledged), 50,000 errors a month kept 30 days, and check locations to add.
- Pro, $15 a month: 10 status pages, 100 monitors across them (50 per page), checks every minute from every region in turn, a year of history, every alert channel, email, Slack, Discord, Teams and webhook subscribers (1,000 per page, more in blocks of 1,000 at $5 a month, or overage at 1 cent per subscriber a month), a monthly uptime report, a password on the page, private pages, an address of your choice, your own domain with the certificate handled, pages without "Powered by StatOSS", incident updates and post-mortems drafted from the check data, components that follow a vendor's public status page, $4 a month of added check locations, 3 people on the team with an audit log kept a year, on-call for the whole team (50 alert sources, escalation policies, schedules and the PagerDuty and Opsgenie import), and 500,000 errors a month kept 90 days.
- Every plan has incidents, templates, maintenance windows and post-mortems, a status badge, status.json, RSS and Atom feeds, an embeddable widget, a read-only MCP endpoint next to the page, and a REST API with keys.
- Billing runs through Polar. The billing page lists what the account costs a month and the next invoice line by line; adding a location, a fixed IP or a block of subscribers asks first with the bill before and after. Payment details, invoices and cancellation are handled on the Polar customer portal, reached from the billing page in the dashboard.
- Cancelling keeps the plan to the end of the paid period, then drops the account to Free. Pages and monitors past the Free limits are paused, not deleted, and start again on a new subscription. History older than the new plan's window is removed within a day.
- Moving between Hobby and Pro takes effect at once with proration. A custom domain stays on a page after leaving Pro but is not served; visitors are redirected to the StatOSS address.

## API and MCP

- A REST API under https://statoss.com/api/v1 (OpenAPI 3.1 at /api/v1/openapi.json, reference at https://statoss.com/docs/api) and a keyed MCP server at https://statoss.com/api/v1/mcp (https://statoss.com/docs/agents) do what the dashboard does with status pages, monitors, alerts, subscribers, the team and API keys. A key from Settings, API keys reads or reads and writes, and reaches every page or one page. A key works while the person who made it can open the team in the dashboard. The dashboard's plan limits and roles apply.
- Pages: POST /pages (create_page) makes one, with a first monitor when given an address; a key for one page cannot. PATCH /pages/{id} (update_page) changes the name, address (Hobby and Pro), words and look. DELETE /pages/{id} (delete_page) deletes it with everything under it; the key must have been made by the team's owner or an admin, and confirm is the page's address.
- Logo and favicon: PUT and DELETE /pages/{id}/logo and /favicon, with the image as the request body (PNG, JPEG, WebP, GIF, SVG or ICO, up to 512 KB). MCP carries JSON, so there is no MCP tool for them.
- Own domain (Pro): PUT /pages/{id}/domain, POST /pages/{id}/domain/check and DELETE /pages/{id}/domain; set_custom_domain, check_custom_domain and remove_custom_domain. The answer says which DNS records to add (the CNAME or addresses, and the TXT record) and which of them a check did not find.
- Access: GET and PATCH /pages/{id}/access; get_page_access and update_page_access. Private pages and a shared password are Pro. A password is never returned, and the list of people on a private page is returned to a write key only.
- Monitors: add, change, remove, and check now (POST /pages/{id}/monitors/{monitorId}/check, twelve a minute for the account); create_monitor, update_monitor, delete_monitor and check_monitor. Incidents: open, plan maintenance, post updates, edit and delete; open_incident, schedule_maintenance, post_update, update_incident and delete_incident.
- Alert destinations: GET and POST /alert-destinations, PATCH and DELETE /alert-destinations/{id}, POST /alert-destinations/{id}/resend and /test. A page's alerts: GET and PATCH /pages/{id}/alert-settings, POST /pages/{id}/alert-settings/test. Subscribers: GET and POST /pages/{id}/subscribers, DELETE /pages/{id}/subscribers/{id}. The team: GET /team, POST /team/invitations, DELETE /team/invitations/{id}, PATCH and DELETE /team/members/{id}. API keys: GET and POST /keys, DELETE /keys/{id}. The MCP tools are list_alert_destinations, add_alert_destination, update_alert_destination, remove_alert_destination, resend_destination_link, test_alert_destination, get_alert_settings, update_alert_settings, test_page_alerts, list_subscribers, add_subscriber, remove_subscriber, get_team, invite_member, cancel_invitation, change_member_role, remove_member, list_api_keys, create_api_key and revoke_api_key.
- An email destination is not used until the link mailed to it is opened. An email subscriber added through the API gets the same confirmation mail as the subscribe form and is not subscribed until it opens the link. The team and the API keys are for the owner's and admins' keys, and the owner is never changed or removed. A key makes keys no broader than itself, and a key made through a connected app is deleted when the app is disconnected or its access revoked.
- Billing, passwords, two-factor sign-in, single sign-on, deleting the account and importing subscribers in bulk are in the dashboard only.

## Privacy, in short

- Stored about account holders: name, email address, a hashed password for email sign-ups, the pages and monitors they create with everything typed into them (including alert destinations and request headers), check results, incidents, subscribers, deploy markers and a hash of each API key.
- Stored about people who read a status page: nothing, unless they subscribe (their address, until they unsubscribe; unconfirmed addresses are dropped after 7 days), unlock a password-protected page (one cookie, 30 days) or sign in to a private one (30 days). Status pages load no analytics. The site and dashboard count page views with Umami on our own server in Denmark, without cookies. Error logs keep a visitor's IP address shortened to its network.
- Full text: https://statoss.com/privacy and https://statoss.com/terms. Security, subprocessors and the data processing agreement: https://statoss.com/security, https://statoss.com/subprocessors, https://statoss.com/dpa.

## Addresses

- Home: https://statoss.com/
- Sign up: https://statoss.com/signup
- Log in: https://statoss.com/login
- Docs: https://statoss.com/docs
- Support: https://statoss.com/support
- Changelog: https://statoss.com/changelog
- Uptime reports: https://statoss.com/uptime
- One month of the uptime reports as JSON: https://statoss.com/uptime/data.json?month=YYYY-MM (per service, location and UTC day: checks, failed checks, uptime, median and 95th percentile response time; and the month's outages)
- A status page: https://<slug>.statoss.com
- Short version of this file: https://statoss.com/llms.txt