PHP, a database, and one line in your crontab
That is the whole list. No Composer, no Node, no Docker and no build step, because the sites you are watching are usually on shared hosting and the monitoring may as well be too.
What it needs, which you probably already have
If you host a WordPress site anywhere, every line below is already true on that account. The installer checks all of them and shows a pass-or-fail list before it writes a single file, so an environment that is missing something is told rather than left half-installed.
| Requirement | Why, and what happens without it |
|---|---|
| PHP 8.2 or newer | An older version refuses to start with a message rather than failing halfway through a page. The floor is the one the suites are actually run on. |
| curl, json, mbstring | The requests, the JSON checks, and text handling. Standard on any host that serves a CMS. |
| SQLite or MySQL | SQLite needs no configuration at all and is the default. MySQL is a choice for later, not a prerequisite now. |
| Write access, twice | The data folder, permanently, and the root folder once so the configuration file can be created. |
| One scheduled task | Every minute, whatever your check intervals are. If you have no crontab at all, a secret URL called by an external scheduler does the same job. |
The checklist is in install.php, the version floor in src/bootstrap.php, read on 3 August 2026.
The three things that actually go wrong
These are worth reading before you upload anything, because none of the three looks like an error. Each one produces an installation that appears to be working, which is the only kind of failure that matters in a tool you stop looking at.
| What you see | What it is | What to do |
|---|---|---|
| Everything installed, no checks ever run | The cron entry points at a PHP binary your host does not use for scheduled tasks. Nothing errors, because nothing runs. | Copy the line from the settings screen instead of writing it. It says "inactive" until a pass has happened, and reverts to that after fifteen minutes of silence. |
| Working fine, on nginx | The rule that denies web access to the database is in a .htaccess file, and nginx ignores those. The database stays readable over HTTP. | Move the data folder above the web root and point the database path at its new location. One line of configuration. |
| Alerts sent, none received | A mail server accepted the message and delivered it nowhere, usually because the sending domain is not fully authenticated. This one caught us, on our own instance. | Send a test from the settings screen and confirm it arrives in an inbox, not in a log. An alerting tool whose alerts go to spam is worse than none. |
The fifteen-minute window and the prefilled cron line are in views/settings.php, the secret-URL trigger and its 403 in cron.php.
One decision to make before uploading
Not which host, and not which database. Where the engine sits relative to the sites it watches, because a monitor installed on the server it monitors cannot report that server down: it goes down with it, and the silence looks exactly like a quiet night.
So put it anywhere else. Another host, the cheapest plan at a second provider, a small machine at home. It costs nothing to get right at the start and it is the only part of an installation that cannot be fixed afterwards without moving everything.
Hosted or self-hosted, including what self-hosting does better
Once, then never again
The installer will not run a second time, and that is a lock rather than a limitation: a form that could rewrite the password of a live installation would be a way in. Reinstalling means deleting the configuration file over FTP or SSH first, which nobody can do from a browser.
Updating is copying the new files over the old ones. The configuration and the data folder are never touched, the database schema upgrades itself on the next request, and two commands are there to confirm the new version is happy on your server before you walk away from it.
The full installation documentation, including o2switch and cPanel specifics
Questions before you install it
Does it really run on shared hosting?
That is what it was built for, rather than something it tolerates. There is no Composer, no Node, no build step and no container, because the sites being watched usually live on shared hosting and the monitoring may as well live next to them. Files uploaded by FTP and one cron entry in cPanel are a complete installation.
How long does it actually take?
The upload is the long part, and it depends on your connection. What follows is one page: the installer shows a checklist of the environment, you choose a password, and it writes the configuration and creates the database. Then one cron line, and one alert channel to test. Nothing in that sequence waits on anything.
What if I get the cron line wrong?
You are told, and that is the part worth knowing before you start. The settings screen shows the exact line, prefilled with the path of the PHP running the page, and it flips to "inactive" if no pass has happened in the last fifteen minutes. A monitoring tool whose own scheduler stopped is the worst possible failure, so it is the one thing the application watches about itself.
Can I move from SQLite to MySQL later, or the other way?
Yes, and neither direction needs a migration to run. The schema is identical apart from column types, it is created and upgraded on the next request, and columns are added rather than dropped. SQLite is the right default up to a few hundred checks a minute; MySQL is for past that, or for a database on another server.
How do I uninstall it?
Delete the folder. There is no system service, no global package and nothing written outside the directory, which is a consequence of having no dependencies rather than a feature anyone implemented. If you loaded the demo data first, one command removes it and leaves the rest untouched.
See what it finds before you install it
The free check runs the same detection on one address, with nothing to set up. What it reports is what your own installation would report.