FTMON Update: Automatic Database Cleanup and Better Status Reporting

What happens when FTMON watches thousands of short-lived processes over several weeks?

The monitoring history is eventually pruned, but until now some of the catalogue entries describing those old processes could remain behind. On a busy workstation, that metadata could consume space that would be better used for recent samples and rollups.

Today’s updates improve that cleanup, make database usage easier to understand, and give MCP users a more useful status response.

Old Process Entries Are Now Removed Automatically

FTMON keeps its database within a 200 MB budget. This is deliberate: it should remain a lightweight local monitor rather than become another database that needs regular administration.

The problem was that old observations could expire while the process entries describing them remained in the catalogue. A machine running browsers, build tools or other high-churn workloads could accumulate hundreds of thousands of dead process identities.

FTMON now reaps these entries automatically.

An entity can be removed when:

• the process or entity has gone;
• it has no remaining samples or rollups;
• it is not referenced by an active incident.

This protects useful history and incident details while removing metadata that no longer serves a purpose.

Reaping runs as part of the normal retention cycle, approximately once per minute. Each pass is deliberately bounded, so a large backlog is cleared progressively without creating a long monitoring pause.

You don’t need to run a cleanup command. Just keep the daemon running.

A Better ftmon doctor Report

The ftmon doctor command now gives a much clearer picture of database use.

Run:

ftmon doctor

The report separates three values that are easy to confuse:

• File size — the current database file allocation.
• Used bytes — pages currently holding useful data.
• Freelist space — pages that have been freed and can be reused.

For example, a database may report:

Database: file=199.8 MB used=193.7 MB
Freelist: 1551 pages (6.1 MB, 3.0%)

This means the database file is close to 200 MB, but 6.1 MB is already available for reuse.

A database does not necessarily become visibly smaller as soon as old entries are removed. FTMON may reuse the recovered pages for useful recent history. It also returns free pages to the filesystem progressively in small incremental vacuum batches.

This is an important distinction: a database staying near 200 MB does not automatically mean cleanup has failed.

Doctor also reports recent catalogue activity:

Reap: last ran 15s ago, 1880 removed
Degradation: never

The first line confirms that automatic cleanup is running. The second tells you whether FTMON recently had to shorten normal retention to remain within its storage budget.

ftmon doctor only reports the current state. It does not trigger reaping or compaction.

No Need to Manually Vacuum the Live Database

FTMON continues to use bounded incremental vacuum during normal operation. Freed pages become reusable immediately, while physical file cleanup happens gradually.

A full SQLite VACUUM would require an exclusive database lock. That is a poor trade for a live monitoring system because sampling and incident processing matter more than making a small database file perfectly compact.

Do not run direct SQL or a full VACUUM against the database while the daemon is active.

For routine use, the automatic retention and incremental cleanup are enough.

MCP Status Now Matches the Dashboard

If you use FTMON through MCP, get_status now includes the same primary readings shown on the web dashboard.

This includes useful current values such as disk usage, memory pressure or event ingestion rate, depending on your enabled monitors. Results are bounded and include clear truncation information, so an MCP client cannot accidentally request an unlimited status response.

Health interpretation is also consistent between MCP and the dashboard. Stale data, configuration errors and unavailable external-check aliases should now appear the same way in both places.

That makes MCP status more useful for questions such as:

• Is the host healthy?
• Which monitor currently needs attention?
• What is the latest primary reading?
• Is a monitor unavailable because its external check is not configured?

Clean MCP Installs Work Again

A recent major release of the underlying MCP SDK removed an interface FTMON currently uses. Because the dependency previously had no upper bound, a fresh installation could select that incompatible release and break ftmon mcp.

FTMON 2.0.0a14 now uses the compatible SDK series. Existing installations that were already working were generally unaffected, but clean installs and rebuilt environments should no longer pick the incompatible version.

What Should You Do?

After upgrading and restarting FTMON, check:

ftmon status
ftmon doctor

You should see a fresh daemon tick, a successful database check, catalogue totals, reap activity, and the new used-versus-free storage figures.

There is no separate database cleanup job to configure. Leave the daemon running and FTMON will work through any existing catalogue backlog in bounded passes while continuing to monitor the system.