A fix tells you the problem has gone. A good resolution note tells you why it happened and how to stop it happening again. Every eWay ticket closes with one, so your team builds a record of what went wrong and what changed, not only a list of closed tickets.
What every resolution note includes
| Section | What it covers |
|---|---|
| Root cause | What actually caused the issue, where it can be identified |
| Steps taken | What the engineer did to resolve it, including any workaround still in place |
| Prevention | Recommendations to stop it recurring, on our side, your side, or both |
You receive the note by email when the ticket is marked Resolved, and it stays in the ticket history in the support portal.
When the root cause is not clear
Some issues are resolved without a definitive cause, for example an intermittent problem that stops before it can be traced, or one caused by a third-party service. In that case the note says so plainly, explains what was ruled out, and describes any monitoring added so the issue is caught with more detail if it returns.
Incident report for P1 incidents
For every P1 (Critical) incident, eWay also provides a formal incident report, including a root cause analysis. Every report follows the same structure, so your team always knows where to find each answer.
At the top, a summary block identifies the incident:
| Field | What it records |
|---|---|
| Incident ID | The reference for the incident, linked to your ticket |
| Severity | The agreed severity, P1 |
| Client | Your organization |
| Status | Where the incident stands, for example resolved or monitoring |
| Affected services | The sites, applications, or services that were affected |
| Environment | Which environment was affected, for example production |
| Incident date | When the incident occurred |
| Report date | When the report was issued |
The report then follows six sections:
- Executive summary: what happened and where things stand, in plain terms for leadership
- Impact summary: what was affected, for whom, and for how long
- Incident timeline: from the first monitoring alert through response, key actions, and restoration
- Root cause analysis: what the engineers investigated, what they found, and the underlying cause, with any contributing factors
- Actions taken: how service was restored, and what has changed so the same failure does not recur
- Conclusion: the final state, and anything still being watched
How to use them
- Act on the prevention section. Recommendations for your team, such as a publishing practice or a plugin to retire, are the cheapest way to avoid the next ticket.
- Share incident reports with stakeholders. The executive summary is written for people outside IT, such as leadership or communications teams, after a visible outage.
- Look for patterns. Several notes pointing at the same cause suggest a larger fix is worth planning. Raise it with eWay and it can be scoped as its own piece of work.
- Keep them. Resolution history is useful evidence for audits, reviews, and future planning.
Questions about a resolution?
Reply to the resolution email. Your reply reopens the ticket with its full history, even if it has already Closed. If you disagree with the root cause, or the recommendations do not fit your situation, say so. It is better to discuss it now than to meet the same issue again.
Related: what happens after you submit a ticket and severity levels and response times.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article