Checking site health and investigating errors

Use Tools → Site Health to check whether your website, server, and database are responding. If something is failing, use Tools → Observability → Logs to look for events around the time of the problem.

Start with the symptom a visitor or teammate experienced. A healthy connection check is useful evidence, but it does not confirm that every page, form, payment, or integration works.

Check current availability

1. Open Tools → Site Health and select Site.
2. In Connection status, check the current Website, Server, and Database status pills.
3. Read the explanation for any warning or failure. Hover over a status pill for its details, including the reported time or reason.
4. Open the affected public page separately and try the same viewing steps that revealed the problem. Record the URL, exact error, and time with your time zone.

A brief Checking state is normal on first load, especially just after setup. The first server check may retry for about a minute. Current results and history can finish loading at different times; Loading history… does not mean the live checks failed.

Interpret each signal separately:

• Website: Live means the public health check or homepage responded successfully. Reachable means the browser received a response but could not inspect all its details. Read the explanation before treating it as a full pass.
• Server: Healthy means the server heartbeat reports a healthy state. Degraded or Unavailable needs investigation alongside the displayed reason.
• Database: Connected means the server reported a database connection. If the server cannot be reached, the database may also show Unavailable because its status could not be checked. That alone does not establish a separate database outage.

If the Website result reports an invalid or missing site address, check the intended public domain and site configuration. If the admin itself will not open, collect the public-page error and contact your site operator or support; you do not need access to Site Health to report an outage.

Read the availability history

The Site tab shows a 90-day history for Website, Server, and Database. Hover over or press a day's bar to see its details.

Green bars represent healthy recorded checks, yellow indicates degradation, and red can indicate an issue or a Monitoring gap. Read the label: a gap means a sample was not recorded, so it is not the same evidence as a check that confirmed a failure.

Read the uptime percentage together with the number of days monitored. A site with only a few days of samples does not have a complete 90-day record. Missed monitoring intervals can also affect the history.

Use the dates to narrow your investigation. A problem recorded yesterday does not mean the site is still unavailable now, and a healthy current check does not explain an earlier interruption.

Investigate a slow page

Open Page Speed and check Homepage page speed. Confirm the Endpoint and Checked time before interpreting the result.

The synthetic measurement times the homepage request from the admin browser until its response body is read. It also checks the response and HTML size. It does not measure every image, script, or interaction on every page of the site.

When available, Core Web Vitals · field data shows measurements collected from actual visitors. Use the sample counts and reported values to judge how much evidence you have. Missing field data can mean there are no recorded samples yet; it is not proof of a performance failure. If a load error appears, use Retry page speed data.

For a problem on a particular article, product, or other page, also open that exact page on the affected device. Note whether it is slow before content appears, while images load, or during an action. Keep that description with the page URL and time.

Open API Latency when admin screens or data requests seem slow. This is a small spot check of selected requests. It shows successful-request counts, browser round-trip timings, and per-endpoint results. Where available, App processing helps distinguish server processing from the rest of the request time.

A slow request that succeeded is different from a failed request. Read the status and failure detail as well as the timing. Missing app timing means that measurement is unavailable; it does not mean processing took zero time. API checks refresh on a slower schedule, so check their timestamp before comparing them with a new incident.

Check a specific service

Assistant. The Assistant runtime card shows the current runtime status and individual checks. Read the specific failure rather than assuming every assistant problem is a provider problem. If it reports missing provider setup and offers Open Providers, follow Connecting and managing service providers. A healthy runtime does not guarantee a particular answer or action will succeed.

The Assistant tab also includes readiness information about tool access. Its Run full test action performs operations against the live site. Leave that action to the person responsible for testing the site; collecting status and error details does not require it.

Robots. The Robots & AI discovery card checks discovery settings, robots.txt, and AI instruction files. Read the failing check and the address it inspected. A passing crawler check does not guarantee a search engine has indexed a page. If the inspected address is wrong or unavailable, resolve that first.

For a failure limited to email, payments, uploads, or another workflow, check that feature's own status and error details too. Site Health helps narrow the problem; it is not a substitute for checking the action that failed.

Find a matching log event

1. Open Tools → Observability and select Logs. Runtime logs require operational read access. If unavailable, ask your administrator to check your feature access.
2. Set Minimum level to Warning or Error to focus on problems. Use Service, Surface, Component, Source, or the Core / Extensions choices when you know which area is affected.
3. Enter part of the error message or a request ID in Search. Compare each event's time with the incident time.
4. Select an event's message to expand its full details. Record the error, service or source, timestamp, and request ID if one is present.
5. Select Pause updates while inspecting a changing list. Use Load older events when available to investigate earlier events; loading older pages also pauses updates.
6. If nothing matches, broaden the search, clear unnecessary filters, or lower Minimum level to Info. Select Refresh to fetch again or Resume updates to return to automatic updates.

Logs appear newest first. The visible list is a loaded window, not necessarily all retained events. Check the retention information above the filters. Some installations have retained logs from multiple services; others show only a limited history from the current running process.

A lower Minimum level only reveals events that were recorded and remain available. It cannot recover expired events or messages excluded by the server's logging level. An empty result may reflect filters, retention, access, or a logging gap rather than the absence of a problem.

Use Activity for recorded actions and outcomes, such as a change made around the incident. Use Logs for runtime diagnostics. Correlating the two by time can help explain what happened without assuming that the most recent change caused the error.

Share useful evidence and confirm recovery

Send your site operator or support a short report containing:

• The site address and affected page or admin area.
• What you were trying to do, what you expected, and what happened.
• The exact error message and incident time, including time zone.
• Whether the issue is ongoing or intermittent, and which visitors or teammates are affected.
• Relevant Site Health results, log events, and request IDs.
• Any known change shortly before the problem started.

Copy JSON copies the currently visible, filtered logs. Export all matching downloads retained events matching the selected filters beyond the loaded page. Choose the smallest useful set and review it before sharing; remove credentials, tokens, and unrelated customer information.

After a fix, reopen the affected page or workflow and confirm the original symptom is resolved. Refresh the relevant health view and check new log events. A green status alone is not enough if the customer's action still fails.

If the outcome of a payment, send, import, or other write action is uncertain, check its recorded result before repeating it. Repeated attempts can create duplicate work even when the browser showed an error.