questions, answered.

niceuptime is a local-first monitoring workspace for Pulse checks, Probe checks, Heartbeats, Incidents, alerts, and status pages.

niceuptime is for people responsible for jobs, public HTTP services, and the operational status they share with customers or teammates.

It connects all three. Monitoring produces Heartbeat evidence, tenant policy derives monitor state and Incidents, alerts surface operational work, and status pages communicate selected service health.

A Pulse or Probe produces Heartbeats. The workspace policy interprets those Heartbeats into state, may open or resolve an Incident, creates alerts for people with access, and can feed selected components on a status page.

niceuptime starts with monitor evidence and keeps the resulting state, Incident, alert, and public-status paths in one tenant-scoped product model. It does not present itself as a standalone alert-routing service.

Visit the public status page for current service information, the Help Center for source-backed guidance, or Contact when you need human help.

A Pulse accepts a Heartbeat from work you run, such as a scheduled job. A Probe sends an outbound GET or HEAD request to a public HTTP or HTTPS target.

A Heartbeat is the normalized evidence that a Pulse check-in or Probe result produced. Tenant policy reads Heartbeats before it changes monitor state or opens an Incident.

You can monitor jobs and services that send Pulse Heartbeats, plus public HTTP or HTTPS URLs through Probe checks.

Yes, when the job or service can call out through a Pulse check. Probe checks only reach public HTTP or HTTPS targets.

Probe checks support public HTTP and HTTPS targets using GET or HEAD. Configure the expected HTTP status and timeout in the monitor policy.

The monitor policy evaluates Heartbeat timing and outcomes against its configured thresholds. A missed Pulse deadline or failing Probe can move the monitor through degraded or down states; successful recovery evidence moves it back toward up.

They keep one late or failed observation from immediately becoming an operational state change. The configured grace period and thresholds define how much evidence is needed before failure or recovery is reflected.

Minimum intervals follow the current catalog: Free: 5 minutes; Pro: 1 minute; Max: 30 seconds.

Probe region access follows the plan catalog. Free includes 1 selected region; Pro and Max support multi-region Probe monitoring.

No. Execution may be shared for the same canonical public target, while tenant policy, Heartbeats, state, Incidents, alerts, and access remain tenant-scoped.

The monitor has no completed evidence yet. niceuptime shows an honest pending state until its first Heartbeat or Probe round can be evaluated.

Pause keeps the monitor available to resume without active checking. Archive removes it from active operational use; neither paused nor archived monitors count toward the active monitor limit.

An Incident is derived from a tenant monitor-state transition, not created directly from an individual Probe result. When the state recovers under the configured policy, the related Incident can resolve.

Probe results enter as synthetic Heartbeats so Pulse and Probe evidence follows the same state and Incident rules. This also keeps tenant policy separate from shared Probe execution.

An Incident records an operational state change for a monitor. An alert is a workspace notification about operational work and can be acknowledged or dismissed without rewriting the underlying monitor evidence.

Acknowledging records that the alert has been seen. Dismissing removes it from the active alert view; neither action resolves a monitor problem or changes its Incident on its own.

Email is the globally available delivery path for current alerts and status-page subscriber updates. The FAQ only describes delivery paths backed by the public product surface.

Monitor thresholds determine when evidence changes operational state. Alert rules and the current on-call assignment determine how workspace alerts are presented after that state exists; they do not replace the monitor policy.

Maintenance windows record planned work over a defined time range. They let the workspace present planned operational impact without treating expected work like an unexplained monitor failure.

An Incident review is a workspace-owned post-incident record with a draft or published state. It is included with Max.

Yes. Free includes 1 hosted status page; Pro includes 3 hosted status pages; Max includes 10 hosted status pages.

A monitor collects and evaluates operational evidence. A status-page component is the selected public presentation of one or more monitor states on a particular page.

Choose the workspace monitors that belong on the page, then arrange their components in the status-page editor. The page only reflects monitors selected for that page.

Public pages are intended for broad access. Unlisted pages use a direct address without normal public discovery, while private pages require authorization before their status content is shown.

Custom domains are available on Pro and Max within their catalog limits. A mapped domain is served only after its provider-derived ownership and routing state is active.

The public page derives its summary from the selected component states and relevant published operational information. It does not invent an overall state from monitors that are not on that page.

Visible monitor history follows the workspace plan: Free: 7 days visible; Pro: 90 days visible; Max: 365 days visible. Public pages render the history available through their selected components and published Incidents.

Yes. Public and unlisted pages support real email subscription, confirmation, suppression, and durable delivery controls within the workspace plan's accepted-subscriber capacity.

Free pages keep the niceuptime attribution. Pro and Max workspaces can turn it off for a published page.

Only an active mapped domain can serve a status page. A parked, stale, inactive, or different-tenant mapping does not grant the page to that hostname; use the managed status-page address until a valid mapping is active.

Yes. Free includes 10 active monitors, a minimum interval of 5 minutes, 1 Probe region, 1 hosted status page, and 7 visible-history days. Free: no card required.

Each active Pulse or Probe monitor counts toward the plan limit. Paused and archived monitors do not count toward the active monitor limit.

The catalog is authoritative. Free: 10 active monitors, 1 team member, 1 status page, 0 custom domains, 100 subscribers, 7 visible-history days. Pro: 100 active monitors, 5 team members, 3 status pages, 1 custom domain, 1,000 subscribers, 90 visible-history days. Max: 500 active monitors, 25 team members, 10 status pages, 10 custom domains, 5,000 subscribers, 365 visible-history days. Intervals are Free: 5 minutes; Pro: 1 minute; Max: 30 seconds; Free includes 1 Probe region and paid plans support multi-region Probes.

Workspace owners can view the current plan, available billing actions, and entitlement-backed usage in Billing. Product surfaces also show an upgrade path when an action needs more capacity.

The action needs a plan-backed capability or more capacity than the current workspace entitlement allows. The prompt should identify the relevant limit or feature instead of silently changing resources.

Pricing shows a monthly option and a discounted annual option for paid plans. The current catalog displays annual paid-plan prices as a monthly equivalent with the annual billing amount beside them.

Owners use Billing to start an eligible plan change or open the managed billing portal for an active subscription. That surface is the source of truth for available billing actions.

niceuptime blocks new actions that would exceed the active entitlement and presents the relevant capacity. Existing resources remain governed by the current workspace policy and plan state rather than being silently deleted.

Yes. niceuptime documents a tenant-scoped management API, including GET /v1/monitors, authenticated with a management API key. Endpoints not listed in the API docs are not public API.

The management API operates tenant resources with a management key. A Pulse URL is a monitor-specific ingestion endpoint that accepts Heartbeats and does not grant general workspace management access.

MCP provides tenant-scoped read and write tools for supported local or self-hosted workflows. It is included with Pro and Max.

Yes. The CLI is a native client for the same product API contract, with its own presentation layer rather than a separate workspace data model.

Management API keys authorize tenant API operations. A Pulse token is limited to Heartbeats for one monitor, and an MCP token carries a read or write scope for one workspace.

Treat management keys, Pulse URLs, and MCP tokens as credentials: keep them in a secret store, share only the narrowest credential needed, and rotate or revoke them from the matching product surface when access changes.

Management API limits are tenant-scoped. A client that receives 429 should respect the response and retry later with bounded backoff instead of immediately repeating the request.

Outbound webhooks are not part of the current public product contract. Use the documented management API and Pulse ingestion paths for available automation.

Monitoring reads and writes are tenant-scoped. Shared Probe execution never shares tenant policy, Heartbeats, state, Incidents, alerts, or access between workspaces.

Owners control workspace ownership and billing. Admins can manage supported workspace operations, while members receive the non-owner access granted by the workspace role model.

Owners and admins invite people into the workspace within its plan-backed team-member capacity. The current catalog allows 1, 5, and 25 team members for Free, Pro, and Max.

Private status pages check access before rendering status content. A visitor without authorization does not receive the private page's operational details.

Private pages are access-controlled before content is rendered and are not a public indexable surface. Unlisted pages use a direct URL and should be shared only with the intended audience; an unlisted URL is not the same as access control.

Visible history follows the catalog: Free: 7 days visible; Pro: 90 days visible; Max: 365 days visible. The catalog's current maximum retention horizon is 365 days; presentation remains bounded by the workspace plan.

Include the workspace, affected monitor or status-page address, the time you observed the issue, what you expected, and any safe-to-share request or error detail. Do not include credentials in a support message.

Use Contact to report a security or privacy concern and include only the details needed to reproduce or assess it. Do not send live credentials or sensitive customer data.