Monitoring

Use several signals to understand production. Host observations describe runtime state; HTTP checks describe reachability; scheduled check-ins describe what your jobs reported. Their freshness matters as much as their latest value.

Runtime and HTTP health

Open a project from Projects to inspect its environments and components. The observer reports what is running on each connected host.

Configure HTTP monitoring for the public URL you care about. A successful check describes that request at that time; it does not establish that every background worker or user workflow is healthy.

For a deployment, configured HTTP and probe signals participate in verification. See deployment receipts.

Errors and response time

For any app deployed with Kamal, the observer also summarizes request counts, server errors, and response time from the kamal-proxy log, with no change to your app. Rails apps can add the optional upstate-rails gem for migrations, jobs, and the slowest actions; Phoenix apps can add the upstate_phoenix plug for migrations and Oban jobs. See App health and Rails and App health and Phoenix.

Certificates and domain registration

HTTPS monitoring can surface certificate expiry. Domain registration expiry is a separate signal based on public registrar data associated with an HTTP check's domain.

Some registrars do not publish an expiry date, and some lookups are unavailable. Upstate shows those gaps instead of inventing a date. Check the source and freshness, then confirm renewal and payment details with your registrar when a warning appears.

An available website can still have a domain approaching expiry. Renewing the domain and replacing a TLS certificate are different actions.

Scheduled jobs and backup check-ins

Open Check-ins to configure a schedule and use its generated ping instructions in the job you own. Keep the generated ping URL private: it contains the credential that reports job status.

A successful backup check-in means your job reported success. Upstate does not run that backup or test a restore. Keep restore rehearsals and backup retention checks in your own operating procedures.

Respond to stale or missing information

Check timestamps before concluding that a previous healthy reading still applies. Investigate missing observer reports separately from failed HTTP requests or missed scheduled runs.

Use alerts and notifications to route actionable changes to the people responsible for the service.