Download the PHP package zeixcom/craftmonitoring without Composer

On this page you can find all versions of the php package zeixcom/craftmonitoring. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of zeixcom/craftmonitoring

Informations about the package craftmonitoring

Craft Monitoring

A token-protected JSON endpoint that exposes information about a Craft CMS installation (versions, plugins, environment, health, available updates) so an external dashboard can keep an overview of all your sites.

It is the agent side: each site runs this plugin and exposes a read-only report; a central dashboard polls every site and aggregates the results.

Installation

Configuration

Copy config.example.php (shipped with the plugin) to your project's config/craft-monitoring.php:

The plugin rejects any secret shorter than 32 characters (it returns 404 as if the endpoint did not exist). Generate a strong secret:

That gives you 64 hex characters (~256 bits of entropy). Put it in .env:

Treat this secret like an admin password — rotate it if it leaks, and never commit it. The matching value lives in the monitoring dashboard's config.

Endpoint

The endpoint is mounted on the CP URL manager, so it sits behind any IP allowlist, basic-auth, or WAF rule scoped to the CP host. If your CP trigger is admin, the URL is https://<site>/admin/monitoring/api/system-report. If you ever IP-restrict the CP at the webserver layer, the dashboard's egress IP must be on that allowlist.

Authentication

The endpoint accepts the secret in any of these places (first match wins):

Method Example
HTTP header X-Client-Secret: <secret>
Authorization bearer Authorization: Bearer <secret>
POST form parameter clientSecret=<secret>
JSON body field {"clientSecret": "<secret>"}

The URL query string is not accepted — secrets in URLs leak into webserver logs, CDN logs, and browser history.

Response

A successful call returns 200 with a JSON body. The top-level reportVersion (currently 1) lets the dashboard evolve independently of the agent — bump it on any breaking change to the payload shape. The body contains reportVersion, generatedAt, craft, php, database, environment, system, updates, health, plugins, modules.

updates

Reads Craft's cached update info only — the monitoring request never makes an outbound call to the update server.

Field Meaning
infoCached false ⇒ Craft hasn't checked recently; the counts below are stale (0/false)
available Total available updates (Craft + plugins)
criticalAvailable A critical/security update is available
migrationsPending Code was updated but migrations haven't run

health

Field Meaning
queueTotalJobs Pending queue jobs (incl. failed); steady growth ⇒ stuck
deprecationWarnings Count of logged deprecation warnings
pendingProjectConfigChanges Project config YAML is out of sync with the database

Any health/update field is null if its probe threw.

Update timestamps in craft

Field Meaning
lastSystemOrPluginUpdateAt Last Craft CMS core or plugin update (use this in the dashboard)
systemInfoUpdatedAt Last craft_info write — includes project config applies

lastSystemOrPluginUpdateAt is derived from migration history (craft and plugin:* tracks) plus a version fingerprint stored in storage/runtime/monitoring/last-system-update.json. Project config applies that only bump systemInfoUpdatedAt are ignored.

When the fingerprint changes but no migration is newer — a plugin upgrade that ships no migrations, or a deploy landing before migrations run — the value falls back to systemInfoUpdatedAt instead of the time the endpoint was polled. It is a high-water mark: repeated calls never move it, and uninstalling a plugin (which deletes its migration rows) can't push it backwards.

Both fields are ISO 8601 with a real offset. Migration times are read as UTC regardless of the server's PHP timezone.

Before 1.1.0, lastSystemOrPluginUpdateAt was stamped with the request time on any fingerprint change, and migration times were parsed in the server's default timezone. Dashboards talking to older installs should prefer systemInfoUpdatedAt.

Because the value is a high-water mark, a wrong timestamp written by an older version survives the upgrade. Delete storage/runtime/monitoring/last-system-update.json once on affected installs to re-derive it.

Security posture

Dev-mode note: with CRAFT_DEV_MODE=true, Craft's debug error page may render slightly different bodies for different 404 sources. With dev mode off (production), all 404s render the same template and the distinction disappears. Monitor production, not dev.

Migrating from an in-repo craftmonitoring module

If you previously ran this as a copied Yii module:

  1. composer require zeixcom/craftmonitoring and ./craft plugin/install craft-monitoring.
  2. Remove the module from config/app.php (modules + bootstrap entries) and delete modules/craftmonitoring/.
  3. Rename config/monitoring.php → config/craft-monitoring.php (the plugin reads its config by handle). The MONITORING_CLIENT_SECRET env var is unchanged.

The route, payload, and storage/runtime/monitoring/ state file are identical, so the dashboard needs no changes.

License

MIT — see LICENSE.md.

All versions of craftmonitoring with dependencies

PHP Build Version
Package Version
Requires php Version >=8.2
craftcms/cms Version ^5.8.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package zeixcom/craftmonitoring contains the following files

Loading the files please wait ...