---
icon: material/heart-pulse
title: "Status Page"
description: "What status.log10x.com monitors, and how to read it from your own monitoring"
---

[status.log10x.com](https://status.log10x.com){target="_blank"} publishes the
health of the endpoints an install or a purchase needs to obtain a license. It
runs on [Upptime](https://upptime.js.org){target="_blank"}: GitHub Actions
probes each endpoint every 5 minutes, commits the result to the
[status repository](https://github.com/log-10x/status){target="_blank"}, and
serves the page from GitHub Pages. Uptime history and past incidents are
public.

A deployed engine never calls these endpoints. Licensing is
[verified offline](license.md) against a public key compiled into the binary,
and metrics go to [your own backend](../run/output/metric/), so a running
pipeline is unaffected by anything on the page.

## What is monitored

| Check | Probe | Max response |
|---|---|---|
| API | `api.log10x.com/health` | 3,000 ms |
| Identity | `auth.log10x.com/.well-known/openid-configuration` | 5,000 ms |
| Licensing | `POST api.log10x.com/api/v1/license/demo`, body must contain `license` | 10,000 ms |

Licensing mints an anonymous demo license on every run, so it exercises the
license Lambda and the KMS signing path end to end. A green Licensing check
means a fresh install can obtain a token.

Everything else log10x operates is monitored internally rather than published,
because no customer deployment depends on it.

## Reading it from your own monitoring

The Upptime data is public JSON and needs no credentials.

=== "Summary"

    Current status and uptime for every check:

    ```bash
    curl -s https://raw.githubusercontent.com/log-10x/status/main/history/summary.json
    ```

=== "One check"

    History for a single check, named after its slug:

    ```bash
    curl -s https://raw.githubusercontent.com/log-10x/status/main/history/licensing.yml
    ```

    Slugs: `api`, `identity`, `licensing`.

To probe the services directly rather than read Upptime's view, use the
endpoints in the table above.

## Incidents

A failed check opens a GitHub issue in the status repository with the failure
detail, updates the page within 5 minutes, and records the outage in that
check's history. A check that answers 200 but exceeds its response-time
ceiling is marked degraded rather than down.