Skip to content

Operational proof

Public proof for a product still earning its reputation.

This page collects the public evidence Luota can honestly show today: product screenshots, demo-workspace proof, live self-monitoring, deploy checks, and current operating limits. Current public status: degraded.
Live statusProduct tourSecurity

Current status

liveDegraded

Generated Jun 04, 05:57 PM UTC from the public web app, API health, database, worker freshness, and dogfood monitor signals.

Dogfood checks

24hself-monitoring

No 24h data

No production self-check results have been recorded in the last 24 hours.

Proof boundary

claimconstrained

Product evidence, not logos.

Luota is pre-customer. This page uses demo, dogfood, deploy, and product evidence instead of invented testimonials, borrowed logos, or implied compliance claims.

Demo workspace packet

What the public proof can and cannot prove.

The packet is deliberately constrained: it lets a technical buyer inspect product surfaces and operating discipline without pretending there is external adoption.

Demo workspace

Scrubbed demo workspace screenshots

Not customer proof

Shows product capability only. It is not a testimonial, logo, SLA, or adoption claim.

Controlled failure drill

Billing-sync failure drill narrative and incident capture

Bad-day path

Demonstrates the incident shape. Real customer failures will have their own payloads, owners, and runbooks.

Self-monitoring

Live status page, readiness checks, and Luota dogfood monitors

Operational proof

Launch-era self-monitoring, not a third-party uptime SLA or long historical guarantee.

Trust surface

Pricing, billing trust panel, security/privacy matrices, docs quickstart

Buying path

Current plans and controls are explicit. No SOC 2 or enterprise support claim is implied.

Evidence table

What is checked publicly.

These are operational checks, not marketing claims. Each row maps to either the public status surface or the deploy verification path.

Public site

15 min

Marketing surface responds and renders.

API readiness

15 min

Readiness endpoint reaches the app, API, database, and worker signal.

Billing webhook

Deploy + cadence

Stripe webhook path is checked in deploy verification and production self-monitoring.

Product smoke

Deploy

Incident lifecycle, billing, backup freshness, and Lighthouse budgets must pass before a runtime deploy is accepted.

Internal incident walkthrough

A launch-era billing-sync failure drill.

This is internal operational evidence, not a customer case study. It shows the incident shape Luota is built to create.

  1. 01 / Expected signal

    billing-sync should start every 15 minutes and close only after entitlement state is updated.

  2. 02 / Missed signal

    The 14:15 UTC run did not arrive inside the grace window.

  3. 03 / Incident opened

    Luota created one incident with the monitor, owner label, last good run, expected time, and alert path.

  4. 04 / Operator context

    The incident included run history, payload tags, deploy SHA, and the runbook pointer needed to decide whether retry was safe.

  5. 05 / Resolution

    The workflow recovered after the upstream retry path completed. The incident was closed with the recovery note attached.

Inspection checklist

The proof path a buyer should inspect.

This checklist is the public version of the same activation path inside onboarding. The product should be judged by whether each object is visible and useful.

  1. 01 / Promise

    The monitored workflow has an expected window and owner path.

  2. 02 / Signal

    The job sends heartbeat, run lifecycle, or freshness evidence from the work itself.

  3. 03 / Drill

    A skipped, failed, or late signal creates one incident instead of a quiet dashboard.

  4. 04 / Evidence

    The incident keeps run history, payload/output context, alert route, and runbook pointer together.

  5. 05 / Handoff

    The operator can acknowledge, recover, resolve, and retain the history for later review.

Product screenshots

Inspect the actual product surface.

Luota dashboard showing active incidents, monitored workflows, and operator context.
Dashboard: current workflow state and open incidents.
Luota monitor setup screen showing schedule, owner, recent runs, and integration context.
Monitor setup: promise, owner, runbook, and integration snippet.
Luota incident detail screen showing status, timeline, payload evidence, and resolution context.
Incident evidence: timeline, owner, alert path, and run history.

Self-monitoring

Luota monitors Luota

The public site, readiness endpoint, billing webhook path, and production self-checks are watched with the same monitor model customers use. The live status page exposes current state and recent self-monitoring signals.

Deploy gate

Runtime deploys have to pass checks

Deploy verification checks health, web rendering, API smoke, incident lifecycle, billing, backup freshness, and Lighthouse budgets before a production runtime deploy is treated as complete.

Current limit

No inflated enterprise claims

Luota does not claim SOC 2, years of public uptime history, a formal SLA, or a large customer base. Confidence should come from visible product evidence, scripted operations, and clear disclosure paths.

Buyer evidence

The product shows the operator story

Screenshots and the demo workspace show monitor setup, run history, payload context, incident timelines, alert paths, and runbook links so a technical buyer can inspect the real workflow before signup.

Need a concrete migration or monitoring pattern? Start with the docs, then adapt the payload to the evidence your operator needs.

Open integration docs