Skip to content
TMXIO TMXIO Support

Use Security, Cron, and Logs

These pages expose different parts of the same operational boundary:

  • Security shows persisted assessment history, known vulnerabilities, filesystem integrity evidence, and the controls available for the selected Website Environment.
  • Cron manages scheduled runtime work when the Website Runtime supports it.
  • Logs provides time-ordered evidence from the Website and its operations.

Use Security to decide what must change. Use Cron to inspect or schedule recurring execution. Use Logs to establish what happened and when.

The Security page records an accepted assessment immediately, keeps its run in history, and refreshes until the run completes, partially completes, or fails. Use Retry assessment after a failed run. A failure code is safe to include when contacting support.

Known Vulnerabilities are grouped by installed component. Each group shows the detected version, evidence freshness, the applicable advisory count, and one primary action. An update remains Verification pending until refreshed inventory confirms that the installed version is outside every affected range. Filesystem findings on Hosted WordPress can offer Fix permissions or Quarantine unexpected file. Quarantine moves the exact file into protected recovery storage and records a recovery identifier; it does not permanently delete the file. The Quarantined files section can restore it to the exact original path while that path remains free, or permanently delete the recovery copy after an exact typed confirmation. Every filesystem mutation records a durable operation and remains in verification until a newer filesystem scan confirms the result. Modified or missing managed files direct you to the matching WordPress component update workflow.

When a WordPress hardening observation is unknown, Scan configuration refreshes the applied runtime evidence before TMXIO offers a setting change. Hosted WordPress reads this evidence from the managed runtime. A healthy Connected WordPress Website reads supported evidence through its connected worker; controls that require the hosted filesystem remain unavailable. Permission repairs show the current and target mode from a non-mutating policy preview before confirmation, then run a fresh filesystem verification.

Long lists use page controls. Changing a page does not change the selected Website Environment or the evidence summary.

Security behavior depends on the Website Runtime and location:

  • WordPress Website Environments include the essential hardening checks. Hosted WordPress Website Environments can also use TMXIO LockDown. A Connected Website with an external Hosting Relationship promotes LockDown but shows it as unavailable because TMXIO does not control the remote filesystem.
  • Node.js Website Environments use package inventory from deployed package metadata for known-vulnerability matching.
  • Static HTML Website Environments can run the baseline assessment, but WordPress hardening and LockDown do not apply.

Treat No known issues as a statement about current collected evidence, not as a guarantee. If evidence is stale, incomplete, unavailable, or has never been collected, resolve that coverage state before drawing a conclusion.

Before changing a schedule, record its current expression, timezone, command, and owner. After changing it, verify the next execution instead of assuming the saved configuration ran.

When investigating an error, start with the smallest time range that contains it. Preserve the first failing event and its correlation or operation identifier.

Review Website logs

Section titled “Review Website logs”

The Platform tab remains the durable history of actions performed through TMXIO. Hosted Website Environments also expose Runtime Log tabs without copying their contents into Platform Logs:

  • Node.js shows Application output.
  • WordPress shows separate NGINX and PHP output.
  • Static HTML shows NGINX output.

Runtime Logs belong to one Website Environment. Select the environment before comparing entries, then narrow the feed by level and a window from one hour to 30 days. All includes lines whose level could not be identified. Use Older and Newer to move through the feed, or Refresh to return to the newest matching entries.

Runtime Logs are read on demand from TMXIO’s operational log store. They are not saved as Platform Logs, and the screen does not provide a live tail. An empty result means no matching entries were found in the selected window; a temporary availability message means the log store could not be queried and should be retried.