Find the status site and your site's admin

The status site manages the running Zotonic installation. A site's /admin manages that site's content and enabled modules. They have different scopes and can use different credentials.

Start with bin/zotonic status to identify your site and its state. Use bin/zotonic open garden to open its configured URL, then follow the site's login or admin route.

In the admin, locate module management and System → Development. The latter appears when mod_development is enabled and your account has access.

If the wrong site opens, inspect the hostname, aliases, and port rather than changing content. Several sites can run inside the same node. See Site configuration and enabled modules and Enable the Development module.

Check running sites

Run:

bin/zotonic status

The output identifies the node and lists site states. Locate garden rather than treating “Running” for the node as sufficient.

If the site is stopped, inspect its enabled setting and startup logs. If the site is not listed, check its application directory, configuration file, build output, and discovery. A hostname error can also send browser requests to another site even when the desired site runs correctly.

Use bin/zotonic sitedir garden to identify the application's location on a running node. Follow with a real request to the site after changing startup configuration.

Check that a site is working

Access needed: Monitoring access; server access for node checks.

1. From outside the server, request a known public page and check its status and expected content.
2. Check certificate validity, redirects, and response time for the public hostname.
3. On the server, use bin/zotonic status to verify the intended node and site states.
4. Check error logs, disk capacity, database availability, and backup age.
5. Use a dedicated account for a safe representative authenticated check when required.
6. Monitor important asynchronous work, such as email and media processing, separately.

Alert on user-visible failure, approaching capacity limits, stale backups, and repeated processing failures. Set thresholds from normal operation and name an owner for each alert; do not create alerts nobody can act on.

A successful HTTP response from a fallback or status page can hide a failed site. Match expected content or a site-specific health response, not just status 200. Keep monitoring credentials out of public check URLs.