[natasha-moore-elastic]

Summary

Resolves https://github.com/elastic/docs-content-internal/issues/1817 and https://github.com/elastic/docs-content-internal/issues/1814.

Adds the Manage AlertZero section, the Watches and Workers page, and a child page that explains how AlertZero builds threat reports. The pages stay hidden in the table of contents.

AlertZero
├── Watches and Workers               what each Watch and Worker does and needs
│   └── Threat reports                how AlertZero builds the threat reports that Continuous Threat Hunt searches for
...
└── Manage AlertZero                  where to start for each management task
    ├── Configure Worker settings     turn Workers on or off, set autonomy, change other settings
    ├── Run a Worker on demand        start a production run from the Workflows page
    └── View execution history        check a Worker's runs and troubleshoot failures

Previews

• Manage AlertZero - An overview with a table that points to each management task.
• Configure Worker settings - The settings for each Worker, grouped by Watch, including autonomy levels and a warning about automatic response actions.
• Run a Worker on demand - How to start a production run from the Workflows page, and how that differs from a test run.
• View execution history - How to check a Worker's runs and troubleshoot a failed run.
• Watches and Workers - A section for each Watch and Worker, covering what it does and what it needs, plus a table that shows how Workers depend on each other. Moved the page to be the first child of the AlertZero page, since it dives deeper into the concepts of Watches and Workers, which are introduced on the AlertZero page.
• How AlertZero builds threat reports - How the threat intelligence workflows collect and enrich reports, what each report contains, the supported threat feeds and their domains, how the workflows behave across spaces, and what AlertZero needs to build reports. Child of Watches and Workers.

Made with Cursor

[github-actions]

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

• Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[github-actions]

🔍 Preview links for changed docs

• solutions/security/alertzero/configure-worker-settings.md
• solutions/security/alertzero/glossary.md
• solutions/security/alertzero/manage-alertzero.md
• solutions/security/alertzero/run-worker-on-demand.md
• solutions/security/alertzero/threat-reports.md
• solutions/security/alertzero/view-execution-history.md
• solutions/security/alertzero/watches-and-workers.md

[github-actions]

Elastic Docs Style Checker (Vale)

Summary: 2 warnings, 1 suggestion found

⚠️ Warnings (2): Fix when the suggestion improves clarity or correctness.

File	Line	Rule	Message
solutions/security/alertzero/configure-worker-settings.md	54	Elastic.Spelling	'triaged' is a possible misspelling.
solutions/security/alertzero/threat-reports.md	36	Elastic.Spelling	'cryptocurrency' is a possible misspelling.

💡 Suggestions (1): Optional style improvements. Apply when helpful.

File	Line	Rule	Message
solutions/security/alertzero/watches-and-workers.md	79	Elastic.WordChoice	Consider using 'deactivated, deselected, hidden, turned off, unavailable' instead of 'disabled', unless the term is in the UI.

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[nastasha-solomon]

@stephmilovic here's the docs for the Hunt Watch and its workers. As a follow-up to our discussion about the threat intel feeds needing docs, I added these docs. If you can review them too, that would be wonderful - thank you!

cc: @natasha-moore-elastic

[bmorelli25]

Did you mean to undo your change to the noisy wording? Looks like this was removed in an earlier commit but added back in in the lastest merge with main (2a24c50). Maybe an accident?

[nastasha-solomon]

I think copilot accidentally changed this when I recently refreshed the UI labels/descriptions in the AlertZero PRs. Here's what Claude reported:

Nobody edited line 47 on purpose. The change came from how the Copilot bot resolved a merge conflict, and that resolution undid part of your own edit.

Commit 2a24c50a3 is the bot merging main into 1817-az-manage, the branch for elastic/docs-content#9144. GitHub shows a merge commit's diff against its first parent, which is your branch. So the removed L47 text is your wording, and the added text is the bot's.

How the conflict happened. Both sides had changed the Detection Watch glossary entry (glossary.md:47):

Version	Rule Tuning	Rule Coverage
Common ancestor	"diagnoses noisy or under-covering rules and proposes tuning changes"	"assesses detection gaps that {{az-hunt-watch}} finds"
main, from #9084 (2026-10-30)	unchanged	added "the" before Hunt Watch
Your commit 2963231 (2026-11-04)	"finds noisy rules and proposes tuning changes tested against past data"	"reviews the detection gaps that the {{az-hunt-watch}} finds"
Bot's resolution	"diagnoses noisy or under-covering rules and proposes tuning changes tested against past data"	"assesses the detection gaps that the {{az-hunt-watch}} finds"

The bot started from main's line and kept only some of your changes ("tested against past data" and "the detection gaps"). It went back to "diagnoses noisy or under-covering" and "assesses". Your commit message for 29632312b lists dropping "under-covering rules" as one of its goals, because that wording came from the old Worker descriptions and isn't in the BC4 copy.

The other glossary changes in the merge look fine. "Potential attack", the BC4 workflow labels, "schedule", and the Hunt Finding/Investigation wording all came through as you wrote them. Only line 47 went wrong, and the branch tip still has the merged version.

Tracing the merge: the line conflicted between the branch and `main`, and I'm checking how the bot resolved it.

The branch commit removed that wording on purpose, so the merge resolution may have put it back. Checking whether the branch still has it and which PR it belongs to.

Nobody edited line 47 on purpose. The change came from how the Copilot bot resolved a merge conflict, and that resolution undid part of your own edit.

Commit 2a24c50a3 is the bot merging main into 1817-az-manage, the branch for [elastic/docs-content#9144](#9144). GitHub shows a merge commit's diff against its first parent, which is your branch. So the removed L47 text is your wording, and the added text is the bot's.

How the conflict happened. Both sides had changed the Detection Watch glossary entry ([glossary.md:47](solutions/security/alertzero/glossary.md:47)):

Version	Rule Tuning	Rule Coverage
Common ancestor	"diagnoses noisy or under-covering rules and proposes tuning changes"	"assesses detection gaps that {{az-hunt-watch}} finds"
main, from #9084 (2026-10-30)	unchanged	added "the" before Hunt Watch
Your commit 29632312b (2026-11-04)	"finds noisy rules and proposes tuning changes tested against past data"	"reviews the detection gaps that the {{az-hunt-watch}} finds"
Bot's resolution	"diagnoses noisy or under-covering rules and proposes tuning changes tested against past data"	"assesses the detection gaps that the {{az-hunt-watch}} finds"

The bot started from main's line and kept only some of your changes ("tested against past data" and "the detection gaps"). It went back to "diagnoses noisy or under-covering" and "assesses". Your commit message for 29632312b lists dropping "under-covering rules" as one of its goals, because that wording came from the old Worker descriptions and isn't in the BC4 copy.

The other glossary changes in the merge look fine. "Potential attack", the BC4 workflow labels, "schedule", and the Hunt Finding/Investigation wording all came through as you wrote them. Only line 47 went wrong, and the branch tip still has the merged version.

[natasha-moore-elastic]

Thanks both! Stash is right – that was a conflict resolution hiccup. I’ve restored the wording from 2963231.

[andrew-goldstein]

Thanks @natasha-moore-elastic for balancing clarity and brevity while covering a lot of AlertZero here! 🙏
LGTM 🚀

[nastasha-solomon]

Hey @natasha-moore-elastic - @andrew-goldstein's suggestions here and here made me wonder if it'd be useful to add a quick reference table to the top of this page.

Right now, readers have to go through all six Worker sections to learn which Workers rely on each other. When users are setting up AlertZero for the first time, they'll refer to this page to decide which Workers to keep enabled. A quick reference table could give them the info they need at that moment, and then they could read more in the sections after if needed.

Here's an example that takes from the Worker sections that are already drafted in this PR. It also shortens the dependency example in the intro, since the table now covers it.

A {{az-watch}} covers one area of security work and includes one or more {{az-workers}}. {{az-workers}} in different {{az-watches}} often depend on each other. The following table shows how they work together.

| {{az-worker}} | {{az-watch}} | What it does | Works with |
| --- | --- | --- | --- |
| [{{az-alert-triage}}](#alertzero-alert-triage) | {{az-triage-watch}} | Classifies alerts and proposes closing false positives. | {{az-rule-tuning}}, which learns from the alerts that {{az-alert-triage}} classifies as false positives. |
| [{{az-attack-discovery}}](#alertzero-attack-discovery) | {{az-triage-watch}} | Groups related alerts into potential attacks and proposes handing them off for a deeper investigation. | {{az-endpoint-analysis}}, which investigates the attacks that {{az-attack-discovery}} hands off. |
| [{{az-continuous-threat-hunt}}](#alertzero-continuous-threat-hunt) | {{az-hunt-watch}} | Hunts your data for activity that matches {{az-threat-reports}} and records the detection gaps it finds. | {{az-rule-coverage}}, which reviews the gaps that {{az-continuous-threat-hunt}} records. |
| [{{az-rule-tuning}}](#alertzero-rule-tuning) | {{az-detection-watch}} | Proposes tuning changes for rules that produce many false positives. | {{az-alert-triage}}. Without it, {{az-rule-tuning}} still works, but has fewer alerts to learn from. |
| [{{az-rule-coverage}}](#alertzero-rule-coverage) | {{az-detection-watch}} | Proposes a fix for each detection gap, such as turning on an existing rule, installing a prebuilt rule, or creating a new one. | {{az-continuous-threat-hunt}}. Without it, {{az-rule-coverage}} has no gaps to review. |
| [{{az-endpoint-analysis}}](#alertzero-endpoint-analysis) | {{az-forensics-watch}} | Reconstructs the attack timeline on an affected host and proposes response actions. | {{az-attack-discovery}}. Without it, {{az-endpoint-analysis}} has no attacks to investigate. |

I left Context Engine and the advanced settings out of the table, since they're features to set up rather than Workers to keep enabled.

[nastasha-solomon]

@natasha-moore-elastic - when you're back next week, feel free to adjust or remove the following changes:

• 7a01343: The threat report sections on the "Watches and Workers" page was going into more depth than the rest of Watches and Workers, so I moved that content to a dedicated child page. The new child page covers how the workflows build reports, what each report contains, the supported feeds, how the workflows behave across spaces, and what AlertZero needs to build reports. It's hidden in the TOC and placed directly under "Watches and Workers" in the TOC.
• 252f89f: Added the quick-reference table from my earlier comment as its own section after the page intro

[nastasha-solomon]

Nice job adding this info and organizing it. Approving!