# Monitor every deploy (/use-cases/rd-product/deploy-watchdog)



Copy this prompt to start your first task:

<Prompt>
  Set up a deploy-patrol automation for [project/repo, production link, key pages]. After every deploy, confirm the site actually works — homepage, key paths, certificate, no errors — and only alert me when something's really broken.
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;Set up a deploy-patrol automation for [project/repo, production link, key pages]. After every deploy, confirm the site actually works — homepage, key paths, certificate, no errors — and only alert me when something's really broken.&#x22; }" />

## What is this workflow? [#what-is-this-workflow]

Monitoring every deploy means hiring a teammate that fetches the real pages and endpoints after each release and confirms the new version is actually live — not just that a "deploy succeeded" notification fired. It stays quiet when things are fine and DMs you the moment something's actually wrong, naming the specific page or endpoint, not a vague "something might be off."

<Callout type="warn">
  This teammate reads and reports, it doesn't act. It never rolls back a deploy, never edits infrastructure or config, and never restarts a service on its own, even when it's confident about the fix. Catching a break fast is the job; deciding what to do about it stays with a person who can see the wider context.
</Callout>

## How to use this workflow [#how-to-use-this-workflow]

<Steps>
  <Step>
    ### Hire a builder teammate [#hire-a-builder-teammate]

    Open **AI Teammates** in the sidebar, click **Hire AI Teammate**, and pick the **Software Engineer** template, or add this as a second responsibility for your existing one. The default bio is generic implementation work. Replace it on the Profile step so it knows this job is verification, not just watching a log:

    <Prompt>
      You watch every deploy and confirm it worked, not just reported as shipped. Fetch real pages/endpoints after each deploy, confirm the change is visible, not cached. Run a daily patrol for availability, error rate, and cert expiry. Stay quiet when things are fine. The moment something's actually broken, DM me immediately with the specific page or endpoint, don't wait for the next check-in. Never roll back a deploy, edit config, or restart anything yourself, flag it and I decide.
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/software-engineer&#x22;, name: &#x22;Software Engineer&#x22;, bio: &#x22;You watch every deploy and confirm it worked, not just reported as shipped. Fetch real pages/endpoints after each deploy, confirm the change is visible, not cached. Run a daily patrol for availability, error rate, and cert expiry. Stay quiet when things are fine. The moment something's actually broken, DM me immediately with the specific page or endpoint, don't wait for the next check-in. Never roll back a deploy, edit config, or restart anything yourself, flag it and I decide.&#x22; } }" />

    [More on hiring →](/ai-teammates/hire-an-ai-teammate)
  </Step>

  <Step>
    ### Connect GitHub [#connect-github]

    The teammate needs to see deploy events to know when a post-deploy check is due. A workspace admin installs the GitHub App once (**Settings → Integrations**), then grants this teammate the repo. [Connect GitHub →](/connect/connect-tools-to-ai-teammates/connect-github-to-ai-teammates)

    <LivePreview component="AssistantIntegrations" />
  </Step>

  <Step>
    ### Choose event-driven or polling [#choose-event-driven-or-polling]

    Before setting up the check, decide how it senses a deploy:

    * **Event-driven (recommended)**: creating a webhook trigger gives you a URL to point your deploy platform at. Real-time and most accurate, but setup for a webhook trigger runs through the `heliox` CLI or the automation-creator skill, not a field in the automation UI. See [Triggers and schedules](/work/automation/triggers-and-schedules) for how it works.
    * **Polling**: the teammate checks deploy or health status on a fixed interval instead. No change needed on your deploy platform, at the cost of the interval's delay.

    Either way, describe the check itself:

    <Prompt>
      On every deploy, fetch the pages and endpoints that should reflect the new version. Confirm the expected change is visible, not cached, and flag it if the old version is still being served.
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Software Engineer&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;On every deploy, fetch the pages and endpoints that should reflect the new version. Confirm the expected change is visible, not cached, and flag it if the old version is still being served.&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;On every deploy I'll fetch the pages and endpoints that should reflect the new version, confirm the change is actually visible and not served from cache, and flag it immediately if the old version is still live anywhere.&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### Catch it when something breaks, and name the specific thing [#catch-it-when-something-breaks-and-name-the-specific-thing]

    A generic "something might be wrong" alert wastes the time it took to notice the problem. The teammate names exactly what it checked and what it found:

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Software Engineer&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;Anything from today's deploy I should know about?&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;Yes, one real issue: the /checkout endpoint is returning a 500 on the payment-confirmation step, started right after today's 2pm deploy, still happening. Everything else I checked (homepage, login, the other API routes in this release) confirms the new version cleanly. I haven't touched anything, this needs a rollback decision or a hotfix, and that's your call, not mine. Certificate expiry and error rate elsewhere are both normal.&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### Add the daily patrol as a second automation [#add-the-daily-patrol-as-a-second-automation]

    Open **Automations** in the sidebar, click **Create via Chat**, and pick this teammate in the New Thread composer that opens:

    <Prompt>
      Every day at 8am, check that the service responds, compare error rate to the normal baseline if a monitoring source like Sentry or Datadog is connected, and check certificate expiry. Roll up the day's deploy count, failure rate, and any rollbacks. Only message me if something needs attention.
    </Prompt>

    <LivePreview component="NewThread" scenario="{ populated: false }" />
  </Step>
</Steps>

**Nothing here needs your approval:** this teammate only reads status and posts to a channel — it never touches infrastructure, so nothing it does is irreversible. See [Control](/ai-teammates/control) for what does pause for sign-off.

## Tips for Better Results [#tips-for-better-results]

| Tip                                                  | Description                                                                                            |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Name the exact page or endpoint on failure           | A vague "something might be off" wastes the time it took to notice. Make the bio require specifics.    |
| Prefer event-driven over polling when you can        | Real-time and more accurate; polling only if a webhook trigger isn't set up yet.                       |
| Keep the daily patrol separate from the deploy check | One reacts to releases, the other catches slow drift (certs, baseline error rate) between them.        |
| Let it stay quiet on success                         | A watchdog that pings you constantly gets ignored. Reserve the DM for when something's actually wrong. |

## Common Questions [#common-questions]

<Accordions type="single">
  <Accordion title="Can this teammate fix a broken deploy itself?">
    No. It reads and reports only — it never rolls back a deploy, edits config, or restarts a service, even when it's confident about the fix.
  </Accordion>

  <Accordion title="Does it need my approval to post an alert?">
    No. Reading status and posting to a channel doesn't touch anything irreversible, so this flow runs on its own.
  </Accordion>

  <Accordion title="What's the difference between event-driven and polling?">
    Event-driven uses a webhook trigger and is real-time and more accurate. Polling checks on a fixed interval instead — no deploy-platform change needed, at the cost of the interval's delay.
  </Accordion>

  <Accordion title="What does the daily patrol check that the deploy check doesn't?">
    Availability, error rate against a normal baseline, and certificate expiry — slow drift that isn't tied to a specific release.
  </Accordion>
</Accordions>

<Cards>
  <Card title="R&D & Product" href="/use-cases/rd-product" description="Back to the R&D & Product use case overview." />
</Cards>