SupportConsole
llms.txtSign in

See how a site is doing with Observe

llms.txt

When something looks wrong with a site, you want one place to look first. The Observe tab of a site is that place. It gathers four things that answer "is it running, did the last release work, what does it say, and what changed?": the heartbeats of its scheduled tasks, the health check that runs after every deployment, its logs, and an activity feed of the last 14 days.

This article walks through the tab, shows how to turn the health check on and choose the address it requests, explains what a failing check does and does not do, and shows how to filter the activity feed to find a change.

Before you begin

  • A site in the Ready state. Logs and the health check need a site that has been created and deployed. See Create a site on your server.
  • View access to the site. Anyone who can see a site can open Observe. Changing the health check needs permission to change the site's settings.
  • For the health check, a page that answers. A path that returns a success status when the application is healthy. Laravel applications have one at /up by default.

1. Open Observe

Open the site from Sites and choose Observe in the row of tabs. The first page is the overview.

The Observe overview of a site
Observe gathers heartbeats, the health check, logs and activity of one site.
  1. Heartbeats. How many heartbeats the site has and how many are missed (for example "1 heartbeat, 1 missed"), with an Open heartbeats link. These are the check-ins of scheduled tasks. See Heartbeats and uptime checks.
  2. Health check. Whether the check is on, the address it requests and the result of the last one, for example "passed (HTTP 200)" with how long ago. Change the health check opens the settings (step 2).
  3. Logs. A shortcut to the site's logs. See step 3.
  4. Activity. The latest five events with View all activity underneath. See step 4.

The page header and the row of tabs stay in place when you move between the Observe sub-pages.

The site tabs and the Observe sub-tabs
Observe has its own sub-tabs.
  1. Observe. The main tab of the site.
  2. Heartbeats. The heartbeats of this site, with the same table as on the server.
  3. Logs. The log reader.
  4. Activity. The full feed.

2. Turn on and tune the health check

A deployment that finishes is not necessarily a deployment that works. The health check asks the new release a simple question straight after it goes live: does the site answer? Open Settings, choose Deployments in the left-hand list, and scroll to Health checks.

The Health checks card in the deployment settings
The health check runs after every deployment; any answer from 200 to 399 passes.
  1. Check the site after each deployment. The switch. When it is on, SrvYard requests the address after the new release is live. Any answer from 200 to 399 passes.
  2. URL or path. A path such as /up, or a full URL on one of this site's own domains. If you leave it empty, SrvYard checks the home page. Press Save to keep the change.

What the result means:

  • Passed. The deployment finishes normally and the Observe overview shows the status and how long ago it ran.
  • Failed. The deployment is marked as failed, the deployment log says that the release is live but the check failed, and SrvYard sends a Site down notification ("a site failed its health check after a deployment") together with the failed-deployment notification.
  • No rollback. SrvYard does not roll back automatically. The new release stays live. If you want the previous release back, open the earlier deployment and use Rollback. See Zero-downtime releases and rollbacks.
Tip

Point the check at a path that exercises something real, such as a small route that reads from the database, rather than a static page. A static page answers happily even when the application is broken.

Note

The health check runs after deployments only. SrvYard does not request your site on a timer. For a view from outside, use an external uptime service, and use heartbeats to watch what runs on the server.

3. Read the logs

Choose Logs under Observe (or the Logs tab of the site). Pick the log, how many lines to show and press Refresh.

The Log menu offers the Nginx access log and the Nginx error log for every site, and, when they apply, the Laravel log and the PHP error log. Lines lets you choose 50, 100, 200, 500 or 1000. The Auto-refresh switch reloads the tail of the log by itself while you watch a request come in. Logs are available once the site is installed.

Logs can contain visitor addresses and request paths. Be careful where you paste them. The page is read-only: clearing logs is a separate permission on the server. More about reading and running commands is in Read site logs and run commands.

4. Follow what changed

The Activity page lists everything that happened to this site in the last 14 days. After that, older events are removed.

The Activity page of a site
The site activity lists the last 14 days: deployments, certificates, domains and more.
  1. Type. A filter. Tick one or more types (Deployments, Servers, Sites, Certificates, Domains, Daemons, Scheduled jobs, SSH keys, Databases and others) to narrow the list. The search box finds a word in the description.
  2. An event row. The type, a sentence about what happened, who did it (SrvYard for things the system did, such as a missed heartbeat, or a member's name) and when. The View button chooses which columns to show.

The feed is a good way to answer "what changed before it broke?": a deployment, a new domain, a certificate that renewed or a heartbeat that went missing show up in order. If you only have access to some servers or sites, you only see the events about those. The same feed exists per server: see The activity log.

A worked example

Visitors report errors at about two o'clock. Open Observe and read the overview from left to right. The Health check card says the last check passed two days ago, so the problem did not come from a deployment. The Heartbeats card shows a missed heartbeat, which suggests that something on the server stopped. Open Activity, tick Deployments and Certificates to rule them out, then clear the filter and read the events around two o'clock: a heartbeat that was not received, and a domain added a few minutes earlier. Finally open Logs, choose the Nginx error log and press Refresh to see what Nginx says. Three short looks, and you know where to dig next.

Troubleshooting

  • The Logs page says "Could not read the log". SrvYard could not open the log over SSH. Check that the server is connected on its overview, then press Refresh.
  • The log is empty. The site has not received requests yet, the log was rotated, or the application writes somewhere else. Try another log in the Log menu.
  • The health check passed but the site is broken. The path you chose answers even when the application is unhealthy. Choose a path that depends on the application and the database.
  • The health check fails right after every deployment. The application needs a moment to warm up (for example after a cache clear) or the path needs a login. Choose a public path, or add a short wait at the end of the deploy script.
  • "Change the health check" opens the wrong page. It opens Settings with the Deployments list item selected. Scroll down to Health checks.
  • Nothing appears in Activity for something I did a month ago. The feed keeps 14 days.
Last updated 2026-10-247 min readNeed help? Contact support
PreviousGet told when a scheduled task stops runningNextSend requests, jobs and exceptions to TraceBeat or Nightwatch