Uptime

Screenshots

Uptime v0.3.0 at 1440 pixels: a real scheduled local check and its recovered incident in Uptime Dev, from the screenshot named in RELEASE.json.

Outside services

The services the project declares it sends data to, each with its reason.

cloudflare

An owner-directed deployment sends the application, migrations, configured Worker bindings and secrets, resource settings, and health requests to the owner's Cloudflare account; Cloudflare hosts the Worker, D1 database, and scheduled Cron.

sendgrid-mail

SendGrid sends hosted sign-in, incident email and monitoring watch mail when selected as the Base mail adapter.

incident-webhook

Owner-configured webhook (custom-webhook) sends to custom destination owner-configured-json-receiver: deliver scheduled incident events to the owner's public HTTPS endpoint. The endpoint runs outside this installation.

slack-incoming-webhook

Slack (slack) sends to provider destination slack-incoming-webhook: post escaped notification content to the owner's incoming webhook. Slack runs outside this installation and accepts the configured remote request.

external-heartbeat

Owner-selected independent HTTPS heartbeat service; optional empty GET while self-check passes. The configured URL is a capability and its path is sent to that service.

runner-watch

Independent webhook or Slack notice configured only in the runner environment.

owner-app-readiness

The local setup/dev/preview lifecycle checks the selected Uptime application readiness endpoint; it may be local loopback or an owner-selected remote origin.

configured-dns-resolver

Private runners and owner tools use their configured DNS resolver. Hosted public checks validate A/AAAA answers through Cloudflare DNS over HTTPS; Workers fetch uses Cloudflare’s public Internet resolver and transport.

public-monitor-targets

The hosted Worker or an explicitly assigned private runner sends scheduled requests to the owner’s public target and optional canary URLs.

site-discovery

The runner performs bounded read-only discovery of the owner's chosen site, following its public redirects and crawling permitted pages and related API/status hosts.

isolated-browser-flow-targets

A fresh runner browser follows owner-defined flows through the filtering proxy; target pages and their public network dependencies receive ordinary browser requests.

runner-control-plane

The separately operated runner uses signed HTTPS requests to the configured Uptime Worker control plane for enrolment, claims, results, discovery, notification custody, and contact.

optional-identity-provider-setup

The shared setup CLI can read selected provider discovery documents. The completed local probe read dependency metadata, then failed at unmounted application dependency approval (404) before owner creation or any provider link request. Uptime does not mount linked-provider routes; runtime OIDC callback, token, JWKS and dependency exchange are unsupported.

optional-management-editor

An authenticated owner page may create the configured management editor iframe while the editor is hidden. This is an explicit private management integration, not a public embeddable widget. This is the explicit BASE-DATA-005 exception: the configured origin may belong to the author and receive opted-in requests; the native product has no operational dependency on this integration.

resend-mail

Resend sends hosted sign-in, incident email and monitoring watch mail when selected as the Base mail adapter.

cloudflare-mail

Cloudflare Email Sending sends hosted sign-in, incident email and monitoring watch mail when selected as the Base mail adapter.

Scope and limits

What it will not do

• Real provider or production target actions before explicit authority and verification
• Public communication, people paging, and independent geographic monitoring
• Fresh-account hosted operation and recipient acceptance remain unverified

Declared limits

Status

estimated-not-tested

Public Requests Per Minute Per Ip

• Documents 180
• Health 180
• Authentication 120
• Setup 180
• Editor 180
• Redirects 180
• Heartbeats 600
• Runner 1,800
• Assets 600
• Development 600
• Drills 30
• Development assets 1,800

Notes

Owner-tunable source settings; each class shares one fixed 60-second D1 window per client. Production assets retain their own budget. Local Vite compiler assets use a separate budget for the unbundled browser graph: about 140 module requests per console load, with room for twelve loads per minute. These defaults are estimated, not load tested. Hosted CF-Connecting-IP must be a valid single IP; missing/malformed values share an unknown-client bucket. Local mode ignores all forwarding headers and uses one loopback bucket. Only keyed hashes of client identities are stored.

Requirements

All 21 clauses of Uptime’s CONTRACT.md. They say what the project must do; the handover and verification records say what is built and tested.

HTTP 1 clause

1. HTTP-001
   Signed HTTP monitoring Public hosted HTTP(S) and keyword checks run in the Cloudflare Worker; private checks use the separately scoped Node runner. They retain the exact immutable assertion bundle and bounded transport evidence, and require authenticated claims and signed results; the control plane must reject contradictory completion. See [Integrity and authority](#integrity-and-authority) and [Network and credentials](#network-and-credentials).

EVIDENCE 1 clause

1. EVIDENCE-001
   Immutable scheduled evidence Definitions, scheduled slots and every retry attempt retain revision, policy, fixed selected probes, runner identity, timings, status, assertions and error category; retries never erase failures, and observation/state/outbox commit atomically. See [Evidence and state](#evidence-and-state) and [Integrity and authority](#integrity-and-authority).

STATE 1 clause

1. STATE-001
   Fixed coverage and incident hysteresis Missing or expired passing coverage is Unknown, partial failure stays visible, independent-vantage agreement and scheduled confirmation determine Failing, and complete fresh scheduled passing evidence plus recovery threshold is required for recovery; manual checks and maintenance never rewrite observations or scheduled policy. See [Evidence and state](#evidence-and-state).

AUTHORITY 1 clause

1. AUTHORITY-001
   Server-side scoped authority Every private document, read, mutation and export requires server-side operator or scoped runner authority, missing configuration fails closed, browser mutations enforce configured origin, and expired/foreign attempts cannot alter current evidence, and duplicate attempt identities cannot overwrite it; a signature identifies a key holder rather than proving truthful observation. See [Integrity and authority](#integrity-and-authority).

NETWORK 1 clause

1. NETWORK-001
   Pinned bounded destination execution Every public DNS answer and redirect hop is validated fail closed; private-runner numeric sockets preserve Host and TLS identity, hosted checks use Cloudflare’s public Internet fetch transport, unsafe/mixed addresses and HTTPS downgrade are rejected, cross-origin redirects strip request authority, and synthetic grants and protected origin-bound local credential files retain their separate custody limits. See [Network and credentials](#network-and-credentials).

HEARTBEAT 1 clause

1. HEARTBEAT-001
   Revision-scoped receipt evaluation Hashed owner-issued tokens and increasing sequences protect server-time receipts, ingress cannot advance health, and scheduled signed completion must match its exact installation-local claim snapshot; stale, future, paused, foreign-revision or imported receipts cannot establish Healthy. See [Network and credentials](#network-and-credentials).

ARCHIVE 1 clause

1. ARCHIVE-001
   Inactive validated restore Bounded versioned archives require integrity and semantic validation before transactional restore into empty product data, preserve historical evidence, erasure receipts and the permanent anonymised action audit, create paused current revisions, interrupt leases and quarantine alerts; installation-local sessions, keys, grants, request credential values, heartbeat authority, contact, webhook and Slack URLs, and signing keys are excluded; destination definitions and retained notification histories are portable, and imported evidence cannot establish current health or replay events. The source erasure journal fences copies made before a later erasure when that journal accompanies the restore. A local CLI receiving checkout must run setup first to establish its owner and settings. The owner accepted this installation-authority and endpoint-credential archive policy on 2026-10-13; it is an intentional replacement, not BASE-DATA-001 equivalence. See [Portability and retention](#portability-and-retention) and [Integrity and authority](#integrity-and-authority).

IMPORT 1 clause

1. IMPORT-001
   Reviewed definition files and inactive imports Versioned monitor definition files are previewed without writes and validated with the editor’s rules. Applying a matching plan creates paused monitors or new revisions that preserve existing enablement, maintenance and runner assignments. Files carry no request secrets or installation authority and cannot enable monitors, issue heartbeat tokens or change notification destinations. Batch undo preserves history and reports revision conflicts. No real third-party export or hosted import has been measured.

   Presentation summary by Run Edit Run: Describe the reviewed definition-file workflow without claiming support proven against real data from a named product. No verified real-data importer record is available. The exact publisher clause remains in the signed manifest and CONTRACT.md. Exact publisher wording is in CONTRACT.md.

RETENTION 1 clause

1. RETENTION-001
   Explicit storage custody Product and observation metadata and legacy development sign-in records have no automatic age/count deletion; operator erasure removes captures for the associated operator, and local reset clears the installation. Expired sessions, authentication/public rate-limit state and short-lived login-attempt counters are cleaned up. Expired or confirmed alert-drill links lose their capability material while drill history stays; retired destination secrets are scrubbed only after owner rotation/deletion and in-flight sends finish; a proven-unsent integration-attempt reservation can be removed while its delivery history remains. Other expired operational records, including discovery jobs, change status and remain stored unless an owner erases the associated entity or resets the installation. Raw target response bodies and probe-request secrets are not retained in observations, webhook and Slack endpoint URLs and signing keys remain installation-local, available email addresses travel as destination definitions, view/archive bounds are not deletion or capacity claims, and retention changes must never silently improve the fixed denominator or historical health. See [Portability and retention](#portability-and-retention).

ERASURE 1 clause

1. ERASURE-001
   Operator-directed entity erasure An owner can erase a monitor with its evidence and dependent notification/heartbeat records, a destination with its credential copies, or an operator while another active owner remains. Monitor erasure requires typing the current monitor name. Each completed erasure returns a receipt with entity kind, per-table counts and completion time, and returns it only after the transaction containing the erasure, audit entry and portability fence succeeds. Requests based on stale monitor or destination state cannot re-create erased rows. The last active owner cannot be erased: local installations use rer reset --yes, while hosted installations require replacement by redeployment. Uptime has no R2 upload feature, so product erasure has no uploaded attachments to remove. Already downloaded archives, messages already sent to external recipients and requests already in progress remain outside local erasure. See [Erasure and audit](#erasure-and-audit).

AUDIT 1 clause

1. AUDIT-001
   Durable anonymised audit Destructive actions, automated notification attempts and operator authentication-mail sends record actor or feature, time, action, subject kind and an opaque subject reference. Audit history is portable and survives erasure of the subject; erasing an operator anonymises its prior actor references. The audit contains no monitor names, target URLs, email addresses or destination URLs. See [Erasure and audit](#erasure-and-audit) and [Portability and retention](#portability-and-retention).

PRESENCE 1 clause

1. PRESENCE-001
   Contact separate from health Only accepted scoped claims and signed results refresh server-time contact, the 120-second freshness threshold never proves process liveness or target health, and restart, unavailable reads and archive omission preserve that distinction. See [Contact, interface and delivery](#contact-interface-and-delivery).

INTERFACE 1 clause

1. INTERFACE-001
   Honest durable operator feedback Textual state/freshness/reasons, immutable history, labels, keyboard controls and responsive layout expose persisted evidence; failed reads show Unknown, action errors survive polling, busy reconciliation excludes controls and editing rejects assertion overrides. See [Contact, interface and delivery](#contact-interface-and-delivery).

NOTIFY 1 clause

1. NOTIFY-001
   Authorized installation-wide destinations An owner may configure email, signed JSON webhook, or Slack incoming webhook destinations for all monitors in one installation; only scheduled incident transitions generate automatic notifications, and a test send cannot change monitor evidence or incident state. The hosted Worker submits email through the configured Base mail adapter and sends webhooks and Slack without a private runner; a private runner can also claim notification work. Destination credentials are installation-local and are not restored from archives. See [Contact, interface and delivery](#contact-interface-and-delivery) and [Network and credentials](#network-and-credentials).

DELIVERY 1 clause

1. DELIVERY-001
   Bounded notification acknowledgement Each event and destination gets one automatic send attempt. A RER relay 429 with Retry-After confirms non-acceptance and queues another submission after that delay. HTTP 500, connection loss, timeout, and unknown outcomes remain uncertain and are not automatically sent again. Accepted means the configured provider or endpoint acknowledged the request; it does not mean a person received, read, or acted on it. See [Contact, interface and delivery](#contact-interface-and-delivery).

PUBLIC 2 clauses

1. PUBLIC-001
   Public landing and documentation At the app origin, / is the unauthenticated Lobby, /docs is public documentation, /setup is first-run setup, and the private operator console and editor are /app and /app/monitor; private documents require an owner session. The separate marketing site serves https://run-uptime.com/ and https://run-uptime.com/run. The app Lobby at / and the marketing landing at the run-site / are distinct surfaces.
2. PUBLIC-002
   Declared sessionless paths and rate limits Every sessionless route and emitted static path is declared in seed.json with its authentication rule and rate-limit class. D1 applies owner-tunable per-client limits in fixed 60-second windows and returns 429 with Retry-After after the class limit. A declaration does not bypass route-specific session, runner, heartbeat or development-key checks. Limit values are marked estimated and not load-tested. See [Public paths and rate limits](#public-paths-and-rate-limits) and [Integrity and authority](#integrity-and-authority).

BOUNDARY 1 clause

1. BOUNDARY-001
   Bounded delivery and operating claims Destinations apply to all monitors in the installation, while runners with the same network label remain one vantage. Provider acknowledgement and stored delivery state do not prove inbox receipt or human notification. Teams, Discord, SMS, on-call paging, incident escalation, and public status communication are outside the product; network isolation, browser execution, and accessibility conformance require separate evidence. See [Contact, interface and delivery](#contact-interface-and-delivery).

DRILL 1 clause

1. DRILL-001
   Recipient-reported alert drills An owner can run an alert drill on one destination: the existing test event with drill wording, sent once through the same path with no automatic resend, plus a one-time confirmation link (random capability, stored only as a bound hash, single use, 24-hour expiry, one drill and one destination). Opening the link shows a page; only a same-origin POST confirms, and unknown, used, expired and foreign links answer 404 alike. The console keeps Submitted, Acknowledged (or Uncertain/Failed with its code) and Recipient confirmed as separate lines, and does not measure whether anyone acted. A confirmed drill is a report by the recipient that one message reached a person at one time. It is never evidence of monitoring, a delivery guarantee or a human response, and it changes no monitor evidence, state or incident. Proof belongs to the destination's current credential: a new address or URL or a rotated secret makes it Never proven, and drill history stays with the installation, so a restored destination is Never proven. See [Alert drills](#alert-drills).

STARTUP 1 clause

1. STARTUP-001
   Required configuration diagnostics A shared configuration table validates required and conditional bindings for the Worker, scheduled entry point, local app, preview, setup, deployment and private runner before each begins work. Missing or malformed required values stop the entry point and name the variable without printing its value; a Worker configuration failure returns 503, including at /health. Hosted mode requires the selected Base mail provider and its sender configuration. See [Configuration diagnostics](#configuration-diagnostics).

FLOW 1 clause

1. FLOW-001
   One isolated browser flow (implementation only, outside the supported public feature set) A flow monitor is a revision like any other: a plain-language intent, a start URL under the public-target rules, an ordered list of steps from a closed vocabulary (go to a page, click, fill a field with a named runner-local credential, wait for or expect text, a URL or an element) and the required outcomes that must all be observed for a pass. It carries no script, expression or secret, and nothing is added to the bounded HTTP path. A runner that has a browser runs each flow in its own process with a fresh private profile, a sanitized environment, one flow at a time and a process-tree kill at the wall-clock limit; all browser traffic goes through one filtering door that enforces NETWORK-001. A runner without a browser reports that, and the flow is Unknown with that reason. Credentials stay on the runner. Each observation keeps an immutable, sanitized step trace and the digest of the revision it ran, and no screenshot or page body. Exceeding any stated bound is a failure naming the bound. A pass is evidence of that flow only. See [Flows](#flows) and [Network and credentials](#network-and-credentials).

Baseline

Selected ownership clauses from the 44 in the project’s BASELINE.md. They are declared requirements; evidence is recorded separately.

1. BASE-DATA-005
   Independence. The deployment makes no request to the marketplace or the seed author. There is no telemetry, phone-home, licence check, or kill switch.
2. BASE-DATA-001
   Export and import. rer export --output FILE produces every record and attachment; rer import --input FILE --yes restores it into an empty deployment; export, import, export yields an archive with equivalent contents.
3. BASE-DATA-004
   Outbound flows. User data leaves the deployment only through externals declared in seed.json → externals. No other outbound request carries user data.
4. BASE-PUBLIC-001
   Privacy. Public surfaces (widgets, booking pages, forms, status pages) set no cookies, load nothing from third-party domains, and send no visitor data before the visitor's first interaction.
5. BASE-SECRET-001
   No leakage. No secret appears in the client bundle, in logs, or in an error response.

View as agent

These publisher documents are copied unmodified from the release. Site presentation summaries and historical screenshots are attributed separately on this page. An agent evaluating Uptime can read them instead of the page.

seed.json

The manifest: capabilities, outside services, extension points, limits, operating cost and deployment needs.

CONTRACT.md

The requirements on this page, in source form.

AGENTS.md

Instructions for the coding agent that maintains an installation.

LICENSE

RELEASE.json

README.md

Source setup, available commands and implementation status.

BASELINE.md

The baseline requirements the project declares.

OPERATIONS.md

How the project is set up, operated and deployed.

ACCEPTANCE.md

What the publisher accepts as a finished release.

publisher-release.json

Every project, with its availability, is in /agents/catalogue.json; the agents page describes the machine-readable files.