Audience: System Admin, Org Admin Related: Documentation Index · Technology, Administration, and Reliability · Users, Permissions, and Authentication · Organizations · Performance and Job Status

This is the day-to-day administration guide for keeping a Blackcap installation healthy. It is intentionally different from the rest of the Blackcap documentation: instead of explaining implementation details, configuration schemas, or how a subsystem is built, this guide focuses on what an administrator should review, when to review it, what actions are safe to take, and what signs need follow-up.

The guide is aimed at recurring operations after Blackcap has already been installed and its primary connections and configuration have been established. One-time setup tasks are linked when they become relevant, but they are not repeated here.

Administrator roles and organization context

Blackcap administration is permission-aware. If an action described here is not available, the current account may not have the required permission or the action may not apply to the current deployment type.

System Admin — platform and host administration, including System, platform AI configuration, packaged application updates, database/system maintenance, regression tests, cross-organization administration, and platform configuration.
Org Admin — administration of the active organization, including its users, backups, organization configuration, AI usage, displays, Noun Project rules, and organization-scoped operational views allowed by the assigned permissions.

The Active Organization matters throughout Blackcap. A System Admin who switches from the Default organization to another organization intentionally operates in that organization's context for organization-scoped pages. Do not assume that being a System Admin means every page automatically shows all organizations. Switch context deliberately before reviewing organization-specific users, jobs, backups, usage, database resources, or activity.

The Default organization is also the platform template for selected organization configuration. Platform-wide regression testing and Default-to-organization configuration push workflows are intentionally centered there.

Recommended operating rhythm

Use this as a starting point rather than a rigid schedule. A busy hosted installation should be reviewed more frequently than a small household Raspberry Pi instance.

When	Recommended review
After an application, Python-package, AI-provider, database, or major configuration change	Check System, Job Status, run an appropriate Regression Test, and watch Performance for regressions.
Daily or whenever users report trouble	Check Job Status for failed/stale work, System → Logs for relevant errors, and the affected feature page.
Weekly	Review backup success, failed/stuck jobs, recent purge activity, Performance trends/slow requests, and AI usage/spend.
Monthly	Review users/security/activity, certificate/DNS health where applicable, package/provider updates, scheduled operations, database health/maintenance, configuration sync status, and a broader regression run.
Periodically and before risky changes	Confirm that recent backups exist and that the expected restore path is understood. A backup that has never been reviewed or restore-tested should not be treated as the only recovery plan.
As needed	Manage emojis, Noun Project rules, display pairing/tokens, user access, support diagnostics, and organization lifecycle actions.

A healthy installation normally has no unexplained failed/stale jobs, recent successful backups, scheduled purge activity, no certificate-renewal warnings, acceptable performance trends, and no unresolved errors in the System logs.

Start with the System page

Navigation: Administration → System

The System page is the main host-level health page for a System Admin. It is the best first stop after an update, restart, package change, certificate warning, or unexplained application problem.

Review:

application Version and, for licensed/package-managed installations, license/compliance status;
current project/configuration paths and deployment/runtime details;
Blackcap Updates for package-managed installations;
Python Package Review for supported source/unpackaged installations;
Certificates & DNS where public HTTPS automation is detected;
Uptime & Reboots when the host has restarted unexpectedly;
Logs for bounded, redacted application/service output;
database parity/system actions when troubleshooting a database or deployment change;
attached e-ink tools on installations that directly own a local panel.

The 🔄 Restart Application button restarts the Blackcap application services that apply to the current environment. It requires confirmation. Use it after a Python package update or another change that requires processes to reload code/libraries. Blackcap checks restart-impact blockers first; do not restart through active backup/restore, regression, update, or other protected work.

See Audit, Access Activity, and Logging, Application Updates, and Database Administration for deeper reference material.

Update Python packages on source/unpackaged installations

Navigation: Administration → System → Package Review

Python Package Review is for source/unpackaged installations where Blackcap owns a normal Python environment. Packaged/compiled installations treat their Python dependencies as immutable release provenance and do not update them with pip from the running application.

Review available updates

Open 📦 Python Package Review.
Select 🔎 Check Current Versions.
Review only the packages Blackcap reports as actionable. Packages already at their highest compatible version are intentionally omitted.
Read the version columns carefully:
- Latest Stable is the newest stable release published by the package source and can be informational only.
- Compatible Target is the version Blackcap has determined can be applied with the other managed dependency constraints.
- Apply always means apply the Compatible Target, not blindly install Latest Stable.
Use the header Apply checkbox to select all recommended compatible changes when you intend to bring the managed requirement set current.
Select Apply Selected Targets to update Blackcap's requirements pins.

A dependency-limited package can legitimately have a newer Latest Stable version than its Compatible Target. For example, if another installed package requires pyee<14, Blackcap can recommend a compatible 13.x update while showing 14.x as informational only.

Install pending packages

After requirements are updated, install the pending mismatches from Package Review. Blackcap intentionally sends pip only a bounded list of direct targets, for example:

/home/pi/inky_env/bin/python3 -m pip install --upgrade "openai==3.19.0"

It does not normally give pip the entire requirements graph in one operation. This is faster and more reliable on low-resource systems such as a Raspberry Pi Zero 2 W and avoids deep dependency-resolution failures seen with large all-at-once pip operations.

When several packages need installation, run additional bounded batches until no managed requirement mismatches remain. pip check is most meaningful after the final explicit requirement batch has been reconciled; temporary dependency conflicts can exist between intermediate batches.

Low-memory full environment reconciliation

For a low-memory source installation, use Copy Full Reconcile Commands instead of asking the running web process to perform a large maintenance operation. The copied commands are environment-specific and:

stop the Blackcap application services for that installation;
compare the current Python environment with the active Blackcap requirements file;
install only mismatches in small direct-target batches;
verify the requirements again without handing the complete graph to pip;
run pip check;
restart the Blackcap services even if reconciliation fails.

After Python packages have changed, use 🔄 Restart Application so the running Blackcap processes load the new libraries.

If the final pip check reports a dependency conflict, do not suppress it. Return to Package Review and verify that the explicit Blackcap pins are mutually compatible before treating the environment as healthy.

Update a package-managed Blackcap installation

Navigation: Administration → System → Blackcap Updates

This section applies only to package-managed Source or Compiled installs. Source/unmanaged installs do not use the Blackcap package updater.

Select 🔎 Check for Updates.
Review the approved target, direction, release notes, and any certificate/restart warnings.
Use Prepare Update to download/verify the approved release without immediately replacing the running application.
When the prepared update is ready and restart blockers are clear, use Apply Update and Restart Blackcap.
Review Update History and the recent-update status after Blackcap returns.
If a previous local release is available and a rollback is required, use the explicit previous-version workflow rather than manually replacing files.

A downgrade is never automatic. Review database downgrade safety and release notes before applying one. See Application Updates and Packaged Distribution.

Refresh AI providers and manage available models

Navigation: Administration → Configuration → Platform → AI Role: System Admin

Refresh provider data periodically and after a provider announces new models or pricing changes.

Refresh the provider

Find the saved OpenAI, Gemini, or Anthropic Claude provider connection.
Select Refresh Available Models.
Leave the modal open while Blackcap contacts the provider and refreshes relevant model inventory and official pricing data.
Review:
- Provider reported;
- Relevant tracked;
- Blackcap usable;
- Ignored;
- Pricing updated — the last time material stored rates actually changed;
- Last updated — the last successful provider/model refresh.
Review New usable models, Relevant provider-only models, and No longer reported.

Blackcap refreshes pricing from the official public pricing information for OpenAI, Anthropic Claude, and Google Gemini. Previously verified prices are preserved when a provider pricing page is temporarily unavailable or only partially parseable. A $ indicator in Edit Provider exposes the known rate details without making the model tile large.

Make a provider-only model usable

A model can appear as Provider only when the provider reports it but Blackcap has not directly declared that model's capability mapping.

Open Edit Provider.
Review the provider-only model and its available pricing/capability information.
Use the compact Make Usable action only when the new model is genuinely API/capability-compatible with an existing model template from that provider.
Map it to the appropriate Blackcap capability template.
Save the provider.
Update or create Quality Profiles only where you intentionally want to use the newly usable model.

Making a model usable does not automatically change existing Quality Profiles.

Deprecate a Blackcap-usable model

A model can be deprecated from the provider when it is no longer wanted for new profile selection, provided no Quality Profile currently references it. Blackcap also checks transcription-model references. If the model is in use, change those profiles first; do not bypass the guard.

Deprecated models remain visible for administration and can be restored later.

See AI Providers and Connections for provider/capability detail.

Review AI usage, AI Seeds, and provider spend

Navigation: Administration → AI Usage Role: Org Admin for the active organization; System Admin within the selected organization context

Review AI Usage regularly when AI features are active, especially after changing Quality Profiles, models, web search, Find & Add, image generation, or other provider-cost drivers.

Check:

usage by use case and provider/model;
AI Seed consumption versus provider cost;
failures, invalid responses, and system failures that should not consume settled Seeds;
What Happened details when a specific request needs reconciliation;
Plan Meals, image-generation, inventory/photo, Support Chat, SQL-query, and other use-case summaries;
provider reconciliation/export data when validating product pricing against provider spend.

A System Admin should intentionally switch to the organization being reviewed rather than assuming the Default organization view represents every tenant. See AI Seeds and Usage.

Manage certificates and DNS

Navigation: Administration → System → Certificates & DNS Role: System Admin Applies to: public deployments where Blackcap detects certificate/DNS automation

The System page is the normal health view; use Certificates & Public Access Configuration only when a change is actually required.

Review:

detected DNS provider;
certificate expiration and days remaining;
renewal timer/state;
certificate issuer;
DNS credential/authorization metadata that Blackcap can safely report;
any Certificate renewal needs attention warning.

Blackcap's GCP public-access model uses Let's Encrypt DNS-01 renewal. A valid certificate is not enough by itself: Certbot also needs usable DNS authorization when renewal occurs. The warning window is intentionally more urgent as certificate expiry approaches.

For Google Cloud DNS, verify the VM/service account remains enabled and retains required DNS IAM permissions. For GoDaddy or a custom hook, follow the provider-specific credential rotation workflow before the certificate reaches the intervention window.

Private Raspberry Pi source installs without an Nginx public frontend do not need the GCP maintenance/certificate model merely to run Blackcap. See Reverse Proxy and TLS.

Push and pull organization configuration

Blackcap supports versioned Default-organization configuration sync for selected domains. This is the recurring way to distribute reviewed defaults; it is different from editing each organization's Configuration page by hand.

Push from the Default organization

Navigation: Administration → Organizations → Organization Configuration Sync Role: System Admin in the Default organization context

Use Push All Domains when all currently approved domains should be offered to eligible organizations.
Use Push Domain when only one domain should move forward.
Normal pushes update organizations that are missing/behind while preserving local organization overrides and current-or-newer values.
Leave Override org settings unchecked during normal administration.
Use Override only for a deliberate System Admin reset where overwriting a local organization choice is intended and understood.

Current sync domains include approved login-provider choices, rendering settings, Noun Project footer settings, and Noun Project rules. Platform-only settings such as purge policy are intentionally not organization-sync domains.

Pull into one organization

Navigation: switch to the organization → Administration → Organization → Config Pull

Use Pull Domain when one organization should receive an approved Default-organization domain. Existing organization choices remain protected unless Override is explicitly selected.

After a push/pull, review the target organization and run a focused regression or functional check when the changed domain affects rendering, login, or display behavior. See Organizations.

Create and manage users

Navigation: Administration → Users

Use the Users page for ongoing account administration rather than directly editing authentication data.

Typical tasks include:

invite a new user with the appropriate role;
resend or revoke a pending invite;
review accepted/expired/revoked invite history when needed;
deactivate/reactivate access according to current permissions;
trigger a password reset;
manage organization membership/role changes;
reset MFA when an administrator-assisted recovery is required;
review user-owned API-token status and ask the user to rotate/revoke tokens when appropriate;
for System Admin workflows, manage personal AI Seed balances through the normal user administration surface where enabled.

Review role assignment periodically. Prefer the least privilege needed for the person's actual job. Do not share API tokens between users; user-owned tokens are intentionally attributable and revocable.

See Users, Permissions, and Authentication.

Review Security and Activity

Navigation: Administration → Security and Administration → Activity

These are useful recurring administration pages that are easy to overlook because they do not normally require configuration changes.

Review Security when investigating login/access concerns, MFA state, linked authentication, user/API-token status, or unusual access. Review Activity when you need the audit trail for configuration changes, administrative actions, recipe/meal/shopping operations, backup events, display activity, AI administration, or other recorded workflows.

The active organization context applies. A System Admin must switch context to investigate organization-specific security/activity rather than expecting a cross-tenant wildcard view.

See Audit, Access Activity, and Logging and GeoIP and Access Location.

Manage backups and confirm recovery readiness

Navigation: Tools → Backups

A healthy backup process has recent successful runs, the intended destination connected, and no unexplained restore/upload failures.

Regularly verify:

the expected destination is active: Local, Dropbox, or Google Drive as configured;
recent scheduled backups completed successfully;
failures are investigated in Backup details and Job Status rather than ignored;
retention is leaving the expected recent backups;
credentials/connections have not expired or been revoked;
an appropriate restore path exists for the deployment type.

For Raspberry Pi/SQLite deployments, Blackcap backups protect the local database and supported application artifacts. For GCP/PostgreSQL, use Cloud SQL backups/PITR for the database and Blackcap backups for the supported configuration/filesystem/organization artifacts; do not assume a Blackcap ZIP replaces Cloud SQL recovery.

Periodically review or test restore behavior in a safe context, especially before high-risk upgrades or major database work. See Backups and Restore and Backup Troubleshooting.

Review Data Cleanup and scheduled purges

Navigation: Administration → Data Cleanup

Data Cleanup is not simply a generic delete tool. Blackcap has domain-aware retention for operational history, jobs, performance data, access activity, AI assets, regression history, backup metadata, lifecycle data, and other resources.

Regularly review:

Platform purge policy and whether the configured scheduled policy is appropriate;
Recent purge activity for successful runs and unexpected counts;
Run Policy Dry Run before a manual broad purge when you want to confirm impact;
Run Policy Now only when you intentionally want to execute the policy immediately;
organization-scoped/manual candidates when a specific cleanup is needed.

To confirm that purges are actually running on schedule, also open Job Status → Scheduled Operations (System Admin) and review the purge task's last result and next calculated run.

Do not use manual purge as a substitute for understanding a recurring failure. If scheduled purges are missing or failing, inspect Job Status and System logs first. See Data Retention and Purge.

Run database health and maintenance actions

Navigation: Administration → Database → Maintenance

Start with provider-appropriate health information and Data Problems/Resource Explorer when investigating a specific issue. Use Maintenance actions intentionally; they are audited and filtered to the current database provider.

SQLite/Pi actions

Quick Database Check — lightweight integrity check suitable for routine verification.
Verify Database — full integrity check; use when corruption is suspected or after a storage incident.
Analyze Database — refresh query-planner statistics after significant data change when performance warrants it.
Run WAL Checkpoint — flush/truncate the SQLite WAL when appropriate.
Vacuum Database — rebuild the SQLite file to reclaim free space; treat this as deliberate maintenance rather than a frequent button press.

PostgreSQL/GCP actions

Verify PostgreSQL Connection — confirms the active database/schema is reachable.
Analyze Database — refreshes PostgreSQL planner statistics.

PostgreSQL server health also exposes database/table sizes, tuple estimates, analyze/vacuum timestamps, pool/connection state, and schema version where available. SQLite-only file/WAL/integrity actions are not offered for PostgreSQL.

Additional database administration checks

The System/Database administration surfaces can also run Direct SQL Audit, Database Parity / Schema Verification, and explicitly confirmed safe additive parity repair where supported. Use these after migrations, deployment changes, or when a schema/provider mismatch is suspected.

The SQL Console is a diagnostic tool, not routine maintenance. Keep queries read-only, respect organization scope, and review any AI-created query before executing it. See Database Administration and Database Troubleshooting.

Run regression tests after meaningful changes

Navigation: Administration → Regression Tests Role: System Admin, Default organization context

Regression testing is one of the most useful ways to verify that an administrative change did not break another workflow.

Run an appropriate regression after:

application/package updates;
broad Python-package updates;
database migrations or repairs;
important AI/provider changes;
organization/configuration behavior changes;
significant display/recipe/planning changes;
a fix for a production defect that should not recur.

Choose the smallest run that answers the question when working iteratively, and use a broader/full run before treating a major platform change as complete. Review the run detail, failures, cleanup status, acting user/organization, request/response details, and any linked Job Status entries.

Use Run and Leave Open or diagnostic-clone workflows only when the retained environment is useful for investigation; clean up temporary/regression organizations when the investigation is complete.

See Regression Testing.

Review regression-test performance

Regression correctness and performance are separate questions. A test can pass and still reveal a serious slowdown.

From Regression Tests, review Test Performance / run-detail performance information for:

slowest tests/steps;
repeated expensive requests;
queue wait versus execution time;
changes relative to recent comparable runs;
operations that moved from normal latency into a clear outlier range.

Then use the main Performance page for the broader system trend around the same period. Avoid treating a single Raspberry Pi outlier as a product-wide conclusion; compare like hardware/deployment and repeat the operation when needed.

Review general performance health

Navigation: Administration → Performance

Performance answers how Blackcap is behaving over time. Job Status answers what work is currently queued/running/failed.

Review:

top-level duration/count/success trends;
page/request and background-job latency;
queue wait time versus actual execution time;
Resource Snapshot for CPU/memory/disk-related context where available;
Slow Requests;
recipe cache/extraction breakdown;
display render versus hardware-write timing;
display content pushes;
email/support timing;
backup/restore timing;
external-list operations;
purge/maintenance timing;
regression performance comparisons.

Use Graphs and View Trend when a point-in-time metric looks suspicious. Look for sustained changes rather than reacting to a single slow request. On Pi hardware, especially a Pi Zero 2 W, interpret CPU/memory-sensitive operations relative to that platform rather than comparing them directly with GCP.

See Performance and Job Status.

Review Job Status and stuck work

Navigation: Administration → Job Status

Check Job Status whenever Blackcap appears to be waiting, a background feature did not finish, a user reports stale results, or Performance shows queue growth.

Start with Summary, then drill into the applicable family:

Recipe Cache;
Display;
Backup / Restore;
Email / Support;
Maintenance;
Other;
Scheduled Operations for System Admin host-level schedules.

Pay particular attention to:

queued jobs that are not draining;
running jobs whose age exceeds normal behavior;
failed jobs needing attention;
safe retryable jobs;
repeated failures of the same job family;
scheduled tasks with an old/failed last result or unexpected next-run state.

For failed jobs, use Retry only when Blackcap explicitly offers the safe retry action. Reviewed marks a failure as investigated. Ignore preserves history while removing it from active failure counts. Do not blindly retry restore, purge, email, or stale display jobs from old context; rerun them from the owning workflow when appropriate.

When Blackcap identifies a stale running job and exposes a stop action, inspect its detail first, then stop it only if it is genuinely abandoned rather than just slow. Low-powered Pi cache/browser work can take materially longer than the same job on GCP.

See Performance and Job Status.

Review application logs

Navigation: Administration → System → Logs

The System page exposes bounded tails from fixed safe log sources and redacts common secrets before display.

Use the controls to choose:

Source;
number of Lines;
Severity (Any, Errors, Warnings, Info);
optional Search text.

Use 📋 Copy Visible Logs when collecting a focused diagnostic sample. Prefer the smallest relevant source/time/error set instead of copying enormous logs into a ticket or support conversation.

When the application cannot render the System page, move to the host-level service/journal tools documented in Deployment Troubleshooting.

Add and organize Blackcap-safe emoji

Navigation: Tools → Emojis Role: System Admin

The Emoji page manages the curated registry Blackcap uses across browser UI, PDFs, generated images, and e-ink output.

Common tasks:

enter one or more emoji and select the destination group;
select Add Emoji;
use the alias editor to add search words without changing the emoji's displayed Unicode name;
open the Editable Picker to add categories, move emoji between groups, or drop an emoji onto the delete zone;
select Save Picker Layout after layout changes;
review cache coverage/status and rebuild the emoji cache when Blackcap indicates generated assets need updating.

Do not treat arbitrary Unicode emoji as automatically safe for all Blackcap output surfaces. Use the managed registry and cache workflow. See Blackcap-Safe Emoji.

Manage Noun Project rules

Navigation: Tools → Noun Project

Noun Project rules map organization-specific menu/meal-plan words to footer icons.

Org Admin: add/edit/delete the current organization's keyword rules.
System Admin: manage organization rules and, in the Default/platform context, the shared Noun Project provider credentials/connection test.

Use Add Noun Project Rule for a new mapping. Review ambiguous/overlapping keywords before adding more rules; a rule that is too broad can produce wrong footer icons across many menu items.

Use Test Noun Project Connection after credential/provider changes or when icon downloads start failing. Organization admins intentionally cannot view or test the shared platform credentials.

If standard Default-organization rule changes should be distributed to other organizations, use the versioned Organization Configuration Sync rather than copying database rows manually. See Menu Rendering and Organizations.

Manage display pairing and tokens when needed

Navigation: Tools → Displays → open a Display

Display token administration is normally occasional rather than routine. Use it when onboarding/replacing a remote client or responding to a suspected/stale credential.

Depending on the display/client type, Display Details can expose:

Pair Code for pairing a client;
Client Token rotation;
Revoke to invalidate the current token;
heartbeat/last-sync/status information;
attached/remote-client linking and service state.

Rotate rather than reuse old tokens when replacing a client. Revoke a token when a client is retired or should no longer connect. After token changes, verify the client reconnects and that content pushes/heartbeats resume.

See Displays and Connections and Remote Pi Client.

Review organization lifecycle and tenant health

Navigation: Administration → Organizations / Administration → Organization

This is another recurring area that is easy to miss in a purely technical checklist.

For active organizations, periodically review:

primary admin/contact status;
membership/users;
AI Seed balance/allotment where used;
backup health;
configuration-sync state;
login/MFA policy indicators as appropriate;
lifecycle status.

Archive/disable/delete are distinct lifecycle actions with different recovery/purge behavior. Do not use Delete as a convenient way to hide an organization. Review export/backup and purge eligibility before irreversible closeout work.

See Organizations.

Review licensing and release provenance

Navigation: Administration → System → License / View License Details

For licensed/package-managed installations, periodically review license status, scope, term/trial end if applicable, compliance, and instance/release identity. Investigate a license/compliance warning before an update or organization-capacity change rather than waiting for user access to be affected.

The System page intentionally shows diagnostic metadata but not private signing material. See Microwave Pie Licensing.

Review scheduled operations

Navigation: Administration → Job Status → Scheduled Operations Role: System Admin

Use this page to make sure automation is actually occurring rather than assuming a configured schedule means it is healthy.

Review the latest recorded start/result/duration and next scheduled run for applicable host tasks such as:

data purge;
scheduled backups;
regression continuation/scheduling;
menu/display refresh operations;
GeoIP update timer;
Let’s Cook/display watcher tasks where applicable.

A task showing Not recorded yet immediately after a new install can be normal. A task that previously ran successfully but has stopped recording results needs investigation through its owning page and System logs/journal.

Review Support Requests when support is enabled

Blackcap users can escalate unresolved issues through Support Requests when that workflow is configured. As part of broader operational support, confirm that support email delivery is functioning, failures are visible in Job Status/Performance, and diagnostic context remains appropriately redacted.

Do not use Support Requests as a substitute for fixing a repeatable operational alarm; recurring backup, purge, job, database, or authentication failures should be corrected at the source.

See Support Requests and Support Chat Administration.

Use API Tester for targeted diagnostics

Navigation: Tools → API Tester

API Tester is not a routine health dashboard, but it is an important administration/support tool when a UI workflow is failing and you need to determine whether the underlying Blackcap endpoint works with the current authenticated role and organization context. Use the registered endpoint inventory, safe examples, current authentication context, and copyable cURL/Postman export rather than inventing unsupported URLs.

Do not use API Tester to bypass a UI confirmation or permission boundary. Destructive or intentionally excluded operations remain protected. See API Tester and Postman.

What not to do as routine administration

Avoid turning recurring administration into direct database/file manipulation.

Do not manually edit provider secrets, token rows, user/password data, or configuration tables when a Blackcap UI workflow exists.
Do not use the SQL Console for routine updates; it is intentionally read-only.
Do not force retries of destructive/external-side-effect jobs merely because they failed.
Do not run VACUUM, full integrity checks, deep display refreshes, or broad purge operations on an arbitrary schedule without a reason.
Do not manually copy Default-organization configuration into tenant rows; use Config Push/Pull so versions and overrides remain tracked.
Do not install arbitrary Python packages into the Blackcap environment outside Package Review/reconciliation unless diagnosing a controlled development environment.
Do not assume a provider's newest AI model is safe to use merely because it appears in the provider list; provider discovery and Blackcap capability support are deliberately separate.

A practical health checklist

When you want a quick answer to “Is Blackcap running well?”, use this sequence:

System — no urgent license/certificate/update warnings; expected version; uptime/reboot history makes sense.
Job Status — no unexplained failed/stale jobs; scheduled operations are recording runs.
Backups — recent successful backup(s) and expected destination/restore path.
Data Cleanup — recent purge activity and no repeated purge failures.
Performance — no sustained latency/queue/resource regression or growing slow-request pattern.
Database → Maintenance — provider health is normal; run a quick/connection check when warranted.
AI Usage — spend/Seeds/failures look consistent with actual use.
Security / Activity — no unexpected access, token, role, or administrative changes.
Users / Organizations — access and primary-admin/lifecycle state are current.
Regression Tests — run after meaningful platform changes and review both correctness and performance.
System → Logs — inspect focused errors/warnings when any of the above looks wrong.

If those areas are healthy and user-facing workflows are functioning normally, there is generally no need to perform additional maintenance merely for the sake of doing maintenance.

When to use deeper reference documentation

This guide tells an administrator what to do operationally. Use the linked canonical pages when you need implementation behavior, permission details, retention rules, deployment-specific commands, or troubleshooting depth:

On this page