Operate Mem0 and Cognee

The technical operation of both engines belongs to the Navin Manager. Navin Enterprise runs no system command; it only reads the health of an engine with GET /v1/memory/engines/{engine_id}/health (see Integration).

Start, stop, restart

Each component runs as a systemd unit of the Manager, navin-<service>-<component>.service, whether native or Podman (Quadlet):

Service	Units
Mem0	navin-mem0-mem0-server, navin-mem0-request-log-pruner
Cognee	navin-cognee-api, navin-cognee-ui (with ui_enabled), navin-cognee-mcp (with mcp_enabled)

The start, stop and restart actions are on the service page in the Manager. A parameter marked "restart" in the generated page applies only after a restart. The request log pruner of Mem0 starts after the server, on the same host.

Health and commands

Service	Descriptor command	Effect
Mem0	configuration	effective configuration (GET /configure, secrets redacted by the server)
Mem0	prune_request_logs	immediate pruning of the request log
Mem0	migrate	Alembic migrations of the app database (also done at every start)
Mem0	logs	last lines of the server journal
Cognee	health_detailed	health of each store and of the model gateway as the API sees it (GET /health/detailed)
Cognee	migrate	alembic migrations and graph and vector revisions (cognee-cli upgrade, python method; with podman the API applies them at its start)
Cognee	logs, ui_logs, mcp_logs	last lines of the journal of the API, of the interface, of the MCP server

The health and readiness checks are described in Installation.

Consoles: the Cognee interface (port 8421, path /dashboard) opens from the console registry of the Manager when ui_enabled is on, with the accounts of Cognee; the Manager never frames it, it opens in a new tab, and the browser calls the Cognee API directly, which must therefore be published with it. Mem0 has no console: its dashboard is not delivered and the Swagger page /docs is not an administration interface.

Upgrade and rollback

Both descriptors declare a stateful service and a backup required before the upgrade (backup_before: true). These are the first versions of the catalog: no earlier version is listed yet as the source of an upgrade (from: []).

• Mem0: after the backup, the step alembic_head applies the Alembic migrations of the release (idempotent at the head, verified by test_mem0_real.py).
• Cognee: after the backup, the API applies at its start the alembic migrations and the revisions of the LadybugDB storage format (ENABLE_AUTO_MIGRATIONS).

Automatic rollback is not supported: the migrations only go forward and the Manager never downgrades them. The way back is the restore of the backup taken before the upgrade, with the artefacts of the previous version that the hub keeps available (ADR-0174).

Backup and restore

Service	Backup	Restore
Mem0 (mem0-pgdump)	pg_dump custom format, without owner nor privilege, of the databases mem0 and mem0_app (memories.dump, app.dump) and online SQLite backup of the history file (history.db); verify reads the table of contents of each dump and checks the integrity of a copy of the history	server stopped, pg_restore --clean --if-exists in one transaction per database, then the history file is replaced
Cognee (cognee-pgdump-ladybug)	API stopped (its stop writes the journal of each LadybugDB file), pg_dump of the database cognee, tar archives of the system root (LadybugDB graphs, session cache) and of the data root, sha256 manifest, then restart; verify checks each sha256, the table of contents and each member of the archives	API stopped, DROP OWNED BY the role of Cognee and the objects of the backup in one transaction, then both roots are replaced

The vector extension stays the one of the provisioning. Both backup, loss, restore cycles were run for real (test_mem0_real.py, test_cognee_real.py): a memory deleted after the backup comes back, a memory written after it is gone; a deleted Cognee dataset comes back with its graph and its vectors. The Cognee backup stops the API while it runs.

Retention

Data	Setting	Default
Request log of Mem0 (request_logs of mem0_app)	request_log_retention_days, pruned every prune_interval_hours by the component request-log-pruner	30 days, every 24 hours
History of the search sessions of Cognee	session_ttl_days	7 days
Mem0 memories, Cognee datasets, graphs and vectors	kept until they are deleted through the API	-

The health of the pruner needs a successful run less than two intervals ago. The business retention of the memories (lifetime, legal hold) is set by the agent policy in Navin Enterprise.

Monitoring: probes, alerts and logs

Neither engine serves Prometheus metrics at its pinned version: the Mem0 server 2.2.1 has no /metrics route, Cognee 1.6.6 pushes OpenTelemetry metrics by OTLP only, and only with the tracing. No component therefore declares a scrape target. Monitoring relies on:

• blackbox probes of /openapi.json and /auth/setup-status for Mem0, of /health and the authenticated check for Cognee;
• the state of the systemd units collected by the node exporter (node_systemd_unit_state), in the rule group navin-memory;
• the logs of each unit and of the Podman containers of Cognee, kept by Alloy (job journal, label unit);
• the traces OpenTelemetry of Cognee when tracing_enabled is on and the otel-collector is bound (python method).

Alert	Condition	Severity
NavinMemoryEngineDown	a unit navin-(mem0|cognee)-* is not active for 2 minutes	critical
NavinMemoryEngineFailed	systemd marked the unit failed for 1 minute	critical
NavinMemoryEngineRestarting	more than 4 state changes in 15 minutes	warning

The rules are checked by promtool check rules and promtool test rules in test_catalog_memory_observability.py. Without a memory unit on the cluster they stay silent.

What is not observable

Without native metrics, neither the number of requests, nor their latency, nor the errors per route, nor the number of memories or datasets, nor the duration of a cognify is measured by Prometheus. The probes tell whether the engine answers, not whether it answers well. For Mem0 no trace is emitted (no OpenTelemetry in the 2.2.1 server). These facts are read in the logs, in the detailed health of Cognee and in the audit events of Navin Enterprise.