Issues and Reports

Outcome

You will know how to use reports and issue views to organize follow-up work, how to apply the find, fix, and verify pattern, and when an issue should leave your team’s queue and become a support ticket.

The Find, Fix, Verify Pattern

The most consistent way to turn monitoring output into resolved issues is a simple three-step loop. Each step is short, but skipping any one of them is how findings linger.

1. Find. Use monitoring, audits, and uptime data to surface the issue. Look at recurring findings and patterns first, since they usually represent the largest amount of resolved work for the least amount of effort.

2. Fix. Make the change in the right place. Template-level findings get template-level fixes; content findings get content fixes; infrastructure findings go to the site’s hosting flow. The goal is one fix that closes many instances when possible.

3. Verify. Re-run the relevant check or audit, or confirm the live behavior, before marking the issue closed. A finding is not resolved until the system that reported it agrees.

Report Types

TMXIO produces two broad families of report. Knowing which one you are looking at changes how you act on it.

Operational

Operational reports describe the live state of the site and its connection to TMXIO. Examples include uptime check history, connection health, recent deploys, and backup status. They answer “is the site working right now, and was it working over the last period?”

Act on operational reports quickly. A degraded uptime trend or a missed backup window is more urgent than most quality findings because the impact is happening now or about to happen.

Audit

Audit reports describe the quality of the site at a point in time. Examples include the Site Auditor results, accessibility findings, and SEO or performance audits. They answer “where could this site be better, and what should we work on next?”

Act on audit reports on a planned cadence. Batch findings by template or component, schedule them into a normal release cycle, and re-run the audit to confirm closure.

When To Escalate

Escalation decision

Most findings can be handled by the team that owns the site. Escalate to TMXIO support when the symptom points at the platform itself rather than at content or implementation. Good signals for escalation are: the issue affects multiple sites in your workspace at once, the issue reproduces only on TMXIO infrastructure and not in a local environment, a documented control in TMXIO does not behave the way the docs describe, or a status surface in TMXIO disagrees with what you can see on the site directly.

Recommended Workflow

1. Review the report briefly and confirm whether it is operational or audit-driven.

2. For operational issues, take action immediately and record the timeline so the resolution is auditable later.

3. For audit issues, batch the findings, schedule a fix window, and assign an owner.

4. Use Lens when the issue needs page-level review, screenshots, or collaboration with a stakeholder who is not deep in the admin.

5. Escalate to support when the issue points to platform behavior rather than content or implementation.

6. Verify every closed issue against the original report so the close is real, not assumed.

What Success Looks Like

• Operational issues are resolved during the same business day they are detected when possible
• Audit findings are scheduled into normal release work rather than handled in a panic
• Every closed item has a verification step recorded against it
• Escalations to support arrive with the site, environment, and report reference already attached