Operating Xferity

Operating Xferity

Operating Xferity means treating file exchange as a managed service rather than a hidden background script.

This page covers the day-to-day operating model: what operators do, what health signals to maintain, what to review proactively, and how to keep the system in a good operational state.

Who this page is for

• operators running Xferity in production
• DevOps teams responsible for Xferity deployments
• on-call engineers picking up Xferity incidents

Daily operator checklist

For production deployments, operators should verify these on a regular cadence:

Check	How
Scheduled flows ran successfully	xferity flow status or UI flow list
No unexpected failures or dead-letter artifacts	CLI logs, metrics dashboard
Worker queue is draining (Postgres mode)	/health/worker endpoint, metrics
No new Active security Posture Findings	UI posture page, API /api/security/posture
Certificate expiry dates still acceptable	UI certificates page, /health/certificates
Audit log file is growing (not stuck)	Check audit path write timestamp
Notification delivery is working	Review recent notifications for key flows

Missing scheduled runs and accumulating failures are the two most common early signals of a problem.

Core operator commands

# Check flow execution status
xferity flow status

# View run history for a specific flow
xferity flow history payroll-upload

# Review logs for a flow
xferity logs payroll-upload

# Trace a specific file through the audit trail
xferity trace payroll-2026-03-15.csv

# Validate all flow and partner config
xferity validate

# Run diagnostics for a flow
xferity diag payroll-upload

# Run a flow once manually
xferity run payroll-upload

# Start a flow in polling service mode
xferity run-service payroll-upload --interval-seconds 300

Web UI operator workflows

When the Web UI is enabled, operators can:

• review flow list with current status and last-run result
• inspect flow run history
• review Flow Crypto Requirements
• review Posture Findings, Active Findings, and Suppressed Findings
• review Partner Crypto Policy per partner
• inspect Certificate and PGP Key inventory
• view AS2 message records (Postgres mode)
• manage users and sessions (Postgres mode)
• manage local-vault secrets (Postgres mode)

Security posture review

The posture engine evaluates crypto, secrets, transport, auth, and flow drift domains across platform, partner, and flow scopes.

Operators should:

1. review Active Findings regularly — these are non-suppressed findings
2. investigate any new regressions in the posture trend view
3. acknowledge and suppress reviewed findings when appropriate
4. not suppress findings without understanding what they represent

Suppressions do not erase findings. They change how findings contribute to Active counts and alert thresholds.

In Postgres-backed mode, posture snapshots are taken hourly and support trend history and regression detection. Regression alerts are delivered through configured notification channels.

Partner communication

When a partner reports a transfer problem, the operator workflow is:

1. xferity flow status to see current state
2. xferity flow history <flow> to find the relevant run
3. xferity logs <flow> to read the recent execution log
4. xferity trace <filename> to confirm what happened to the specific file
5. check partner endpoint health with xferity diag <flow>
6. check the audit record for the run in question

Never assume a partner report is accurate. Confirm from the Xferity side first.

Configuration change workflow

When changing configuration, partner definitions, or flow definitions:

1. make the change in version control
2. run xferity validate against the changed files
3. run xferity diag <affected-flow> to check endpoint reachability and trust
4. run the flow once manually before re-enabling schedules
5. review logs and audit output after the first run

Do not re-enable schedules before a successful manual run.

Secret rotation

When rotating a credential:

1. update the secret in the external store or environment
2. confirm the new secret resolves correctly (use diag — it executes credential checks)
3. verify the flow runs successfully after rotation
4. check the posture page for any secret-related findings after rotation

If a flow uses local-vault secrets (Postgres mode), use xferity vault seed to update the value.

Certificate lifecycle

Certificates have expiry dates. Operators should:

• monitor the cert expiry warning window (configurable in security.key_expiry_warn_days)
• rotate certificates before they expire
• rebind the replacement certificate in the inventory before the old one expires
• confirm the posture page clears the cert-expiry finding after rotation

Expired certificates cause flow failures at the trust verification step, not at configuration load.

Reviewing dead-letter artifacts

When a file goes to the dead-letter path, it means the flow could not process it successfully after exhausting retries.

Recovery steps:

1. identify the dead-letter file and the relevant flow
2. read the logs to understand why it failed
3. fix the underlying problem
4. move the file back to the source location and rerun the flow if safe

Do not delete dead-letter artifacts without understanding the failure first.

Common operational mistakes

• enabling schedules before a manual run succeeds
• not reviewing posture findings until a partner escalation
• rotating secrets without confirming the new value resolves
• bypassing host key verification to “get it working” without tracking it as a finding
• not monitoring dead-letter paths for accumulation
• treating audit logs as infinite — forgetting to plan retention and export

Operational discipline

Good Xferity operation means:

• config and flow files are in version control
• changes go through validation before production
• failures are reviewed and root-caused, not just retried
• posture findings are reviewed on a known cadence
• dead-letter and retry signals are monitored
• audit evidence for important exchange paths is exported and retained externally

Related pages

• Monitoring Transfers
• Investigating Failures
• Retry and Recovery
• Audit Investigation
• Backup and Disaster Recovery
• Troubleshooting
• Security
• Observability