Skip to main content
What you’ll get: a shared standard for rating investigations, so the skills ewake writes from your feedback are ones you would have written yourself.
Feedback is not a satisfaction score. Every rating you submit in Slack is read back against the run it rated, and can create or rewrite a skill that takes effect on the next investigation. A careless πŸ‘Ž teaches a careless rule.

Where feedback comes from

Reacting with :thumbsup: is not feedback. Use the buttons under the message.

What happens after you submit

1

You click πŸ‘ or πŸ‘Ž

A form opens: Help us improve Ewake.
2

You pick dimensions and (optionally) write details

On a πŸ‘Ž at least one dimension is required. On a πŸ‘ the dimensions are optional. The Additional Details box is always optional β€” but it is the part that carries the lesson.
3

Ewake acknowledges immediately

You see β€œThanks! We’ve flagged this for the team.” β€” that is the save, not the learning.
4

A curator re-reads the run against your feedback

In the background, ewake replays the transcript of the run you rated, your selected dimensions, your comment, and the catalog of active skills. It decides whether the run teaches a lesson worth keeping.
5

A skill is written or sharpened β€” and goes live

If there is a lesson, the curator either rewrites an existing skill’s body or writes a new skill. Both are activated immediately, with your feedback recorded as the reason for the change.
This is by design β€” a correction you give today applies to tomorrow’s alert without anyone having to promote it. It is also why the wording of your feedback matters: nothing sits in a review queue between you and the next investigation.
6

Ewake replies in the thread

β€œThanks for the feedback β€” we learned from it. β€’ New skill: …” Silence means the curator judged that the run added nothing worth carrying forward β€” which is a valid outcome, not a failure.

What the curator can and cannot see

It reads a condensed transcript of the investigation:
  • the messages of the run, each truncated at ~2,000 characters
  • the names of the tools the agent called, in order, and whether a call failed
  • at most 60 messages β€” a long run keeps its opening and its conclusion, and says so in the middle
It does not see tool arguments, raw tool output, your dashboards, the ticket, the Slack conversation that happened elsewhere, or what turned out to be true afterwards.
Assume the curator knows what ewake looked at, not what it found, and nothing about the world outside the run. Anything you leave implicit is lost.

Choosing the right dimension

The dimension tells ewake which kind of mistake or success it was. Picking the wrong one sends the lesson to the wrong place.
Diagnosis and presentation are separate judgements. An answer that found the right root cause but buried it is Hard to Read, not Missed the Mark. Flagging it as the latter teaches ewake to investigate differently when the investigation was fine.

Writing the comment

The comment is the only place you can say what the right answer was. A good one contains three things:
  1. What ewake concluded β€” briefly, so the lesson is anchored.
  2. What was actually true, and how you knew.
  3. The rule a future run should follow, stated so it generalises beyond today.
Rules of thumb
  • Name services, metrics and thresholds. β€œauth-api p99 over 2s” teaches; β€œthe upstream service was slow” does not.
  • Write the rule, not the incident. The curator is told never to mention your run in the skill body β€” so give it something that still makes sense next month.
  • One lesson per rating. Two unrelated complaints in one comment tend to produce one muddled skill.
  • Do not write instructions to a person. The skill body is read by the agent as prior knowledge to weigh against its own evidence, not as an order to obey.
  • Leave out links and ticket ids. They are stripped when a skill is written, so they cost you space and teach nothing.

Praise is training too

A πŸ‘ goes through exactly the same curation as a πŸ‘Ž. Rating a genuinely good investigation is how the ordering that worked becomes the ordering ewake reaches for next time. Rate πŸ‘ when the run changed what you did next. Do not rate πŸ‘ as a thank-you for a run you did not read β€” it is treated as a lesson either way.

When not to leave feedback

  • The gap is a missing integration, not a mistake. If ewake could not see the data, no skill fixes that. Connect the source instead.
  • You are asking for a product change. Send it to support@ewake.ai β€” the curator can only write skills.
  • Someone already rated the same run for the same reason. Each submission starts its own curation pass; two people making the same point can produce two overlapping skills.
  • You have not read the answer. A reflex rating is indistinguishable from a considered one.

Reviewing what your feedback taught

Everything the curator writes is visible and reversible in the dashboard under Skills:
  • The skill’s version history shows each change, who made it, and a per-field explanation of why it changed, ending with the feedback it came from.
  • Activate this version puts a previous version back in service.
  • The status toggle disables a skill without deleting it; Archive retires it.
Worth doing weekly for the first month: open Skills, read what was written from the week’s feedback, and disable anything that reads like one team’s preference rather than a rule about your production system.

A short checklist

Before you submit:
  • I read the answer and know what it got wrong or right.
  • My dimension matches the kind of problem (diagnosis vs. evidence vs. presentation).
  • My comment names the correct answer and how I know.
  • My comment states a rule that will still be true next month.
  • I would be happy for this rule to apply to the next investigation, unreviewed.

Need help? Contact support@ewake.ai.