Tiki includes tiki-monitor.php, a JSON endpoint that can be used by monitoring systems such as Nagios, Zabbix, Icinga, and Shinken. It reports selected application health values and supports IP restrictions, token-based authentication, role-based data visibility, custom probes, and custom HTTP status codes for failed probes.

For complete monitoring, use tiki-monitor.php together with ordinary system and web checks.

Nagios / Icinga / Shinken examples

• Ensure required services are running.
  • Apache or another web server
  • MySQL or MariaDB, including test queries with tools such as check_mysql
• Ensure adequate memory, CPU, and disk space are available with tools such as check_mem, check_load, and check_disk.
• Ensure the web site is reachable.
  • Use check_http to check a specific page.
  • Use check_webinject to script a login or more detailed site workflow.
• Track site performance over time with tools such as pnp4nagios or nagiosgraph.

The endpoint is available at the root of a Tiki installation:

https:///tiki-monitor.php

Replace with the real domain of the Tiki site.

If the monitor_token preference is empty, anyone who can reach the endpoint can access the public monitor data, subject to any IP restrictions configured with monitor_restricted_ips.

curl https:///tiki-monitor.php

For public sites, configure a token before exposing tiki-monitor.php.

Set the monitor_token preference to require authenticated monitoring requests. When monitor_token is set, requests with a missing or invalid token return 401 Unauthorized.

The configured token value can be passed as:

• a GET or POST parameter named monitoring_token
• an HTTP header named X-Tiki-Monitoring-Token

curl "https:///tiki-monitor.php?monitoring_token=your_token_here"

POST parameter

curl -X POST https:///tiki-monitor.php \
  -F "monitoring_token=your_token_here"

HTTP header

curl -X POST https:///tiki-monitor.php \
  -H "X-Tiki-Monitoring-Token: your_token_here"

Prefer HTTPS so the token is not sent in clear text. Prefer the header method when URLs may be logged by proxies or monitoring tools.

Use monitor_restricted_ips to define a comma-separated list of IP addresses allowed to access tiki-monitor.php.

127.0.0.1,192.168.1.10

Requests from other IP addresses return 403 Forbidden.

Configure the monitoring preferences in tiki-admin.php?page=performance, under the Monitor tab.

A successful request returns JSON. The exact values depend on the server, PHP opcode cache, scheduler setup, database state, search index state, and configured monitor rules.

{
  "OPCodeCache": "OPcache",
  "OpCodeStats": {
    "opcode_cache": "OPcache",
    "stat_flag": null,
    "warning_check": false,
    "warning_fresh": false,
    "warning_ratio": false,
    "warning_starve": false,
    "warning_low": false,
    "warning_xcache_blocked": false,
    "hit_hit": 0.99,
    "hit_miss": 0.01,
    "hit_total": 234249,
    "memory_avail": 0.37,
    "memory_used": 0.63,
    "memory_total": 132057840
  },
  "DbRequiresUpdate": false,
  "SearchIndexRebuildLast": "1784681759",
  "SchedulerLastRun": 1752834313,
  "SchedulerHealthy": 0,
  "Probes": {
    "result": "OK",
    "details": []
  }
}

Common fields:

• OPCodeCache: detected PHP opcode cache, for example OPcache.
• OpCodeStats: cache health and memory statistics. Values such as memory_used are ratios, so 0.63 means 63% used.
• DbRequiresUpdate: true when Tiki detects pending database updates, otherwise false.
• SearchIndexRebuildLast: timestamp of the last unified search index rebuild for the configured search engine.
• SchedulerLastRun: Unix timestamp of the last recorded scheduler run, or 0 if no run is recorded.
• SchedulerHealthy: 1 when scheduler execution is configured, 0 when it is not.
• Probes: overall custom probe status and per-probe details. Without configured probes, the default is OK with an empty details list.

monitor_rules controls which JSON fields are visible to public and authenticated requests. Each rule has the form MonitorName:role, one per line.

The supported roles are:

• public: available without token authentication.
• auth: available to admin sessions or requests authenticated with the configured monitor_token.

OPCodeCache:public
OpCodeStats:public
DbRequiresUpdate:public
SearchIndexRebuildLast:public
*:auth

Example custom rules:

OPCodeCache:auth
SearchIndexRebuildLast:public
OpCodeStats.opcode_cache:public
OpCodeStats:auth
*:auth

With these rules, public users see only selected values, while authenticated requests can see broader data. Rules can target nested values, for example OpCodeStats.memory_used:public.

Use monitor_probes to define specific checks using Tiki calculation syntax. Add one formula per line.

(equals SchedulerHealthy 1)
(less-than OpCodeStats.memory_used 0.85)
(less-than SearchIndexRebuildLast NOW)

The endpoint reports probe results in the Probes section:

{
  "Probes": {
    "result": "OK",
    "details": {
      "probe_1": "OK",
      "probe_2": "OK"
    }
  }
}

If one or more probes fail, Probes.result is set to FAIL and each probe status is listed in details.

When a probe refers to a timestamp value, a numeric probe value can be interpreted as an offset in minutes by the monitor script. The special value NOW is replaced with the current Unix timestamp.

The endpoint supports ordinary GET and POST requests. It also checks monitoring_error_code, or the X-Tiki-Monitoring-Error-Code header, when probes fail.

If Probes.result is FAIL and the supplied code is between 200 and 599, Tiki sends that HTTP status code.

GET parameter

curl "https:///tiki-monitor.php?monitoring_error_code=503"

POST parameter

curl -X POST https:///tiki-monitor.php \
  -F "monitoring_error_code=503"

HTTP header

curl https:///tiki-monitor.php \
  -H "X-Tiki-Monitoring-Error-Code: 503"

For HEAD requests with a failing probe and a valid custom error code, the endpoint sends the status code and exits without a JSON body.

Tiki includes helper scripts for monitoring integrations:

• doc/devtools/check_tiki.php reads tiki-monitor.php and can check opcode cache memory, database update status, and search index freshness.
• doc/devtools/check_tiki-new.php is a separate helper that checks tiki-check.php?nagios from the base Tiki URL. It does not use tiki-monitor.php.

php doc/devtools/check_tiki.php \
  -u "https:///tiki-monitor.php?monitoring_token=your_token_here" \
  --bccwarn 80 --bcccrit 90 \
  --sirwarn 86400 --sircrit 172800

Before using the helper script, verify that the same URL returns JSON:

curl "https:///tiki-monitor.php?monitoring_token=your_token_here"

Example for check_tiki-new.php:

php doc/devtools/check_tiki-new.php \
  -u "https://" \
  --user "username" --pass "password"

The -u value must include the URL scheme, such as https:// or http://.

For simple uptime tools, a direct HTTP check is enough:

curl --fail "https:///tiki-monitor.php?monitoring_token=your_token_here"

• tiki-monitor.php
• doc/devtools/check_tiki.php
• doc/devtools/check_tiki-new.php