> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senderz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing and monitoring

> The publish checks and what each one means, the live-health warning, test runs, adding past profiles, version history, and the per-step and per-automation reports.

Building an automation is only half of it. This page covers everything from the moment you press **Publish**: what Senderz checks, what to do when a check fails, how to test safely, and where the numbers live once it is running.

## Before you can publish anything

Your workspace has to accept the sending compliance step in onboarding first. Until it does, every publish is refused with:

> Sending compliance must be accepted before publishing. Complete the compliance step in onboarding.

This is a one-time workspace setting, not a per-automation one. Once it is accepted, it never blocks you again.

## What publish checks

Senderz runs the same checks in the editor and again on the server, so nothing gets through by refreshing the page.

### Checks that always block

<AccordionGroup>
  <Accordion title="Add a trigger before publishing" icon="bolt">
    The automation has no trigger, or the trigger card exists but no trigger
    event was ever saved on it. An automation with no trigger has no way to
    enrol anyone.
  </Accordion>

  <Accordion title="Every step must be connected to the trigger" icon="link-slash">
    One or more steps cannot be reached by following connectors down from the
    trigger. This usually happens after you delete a step in the middle of a
    sequence and leave the ones below it floating. The message names the
    stranded steps. Reconnect them or delete them.
  </Accordion>

  <Accordion title="Every message step is still a draft" icon="pen-to-square">
    Message steps are created as drafts, and a draft step is skipped at send
    time. If every message step in the automation is a draft, and the
    automation has no data step either, publishing it would enrol contacts and
    deliver nothing at all.

    Senderz offers to fix this for you. Press Publish and you get **Set all
    message steps live?**, which flips every step that has content to Live and
    then publishes. Steps with no content stay drafts and are named in the
    dialog.

    An automation that only tags a profile, updates a list, notifies your team
    or calls a webhook has no message steps to check, and publishes on its own.
  </Accordion>

  <Accordion title="A live step needs content" icon="file-circle-exclamation">
    A message step set to Live must have something to send. For email, SMS and
    push that means a template. For WhatsApp it means an approved template
    name. Either add the content or set the step back to Draft.
  </Accordion>

  <Accordion title="A live email step has an invalid reply-to address" icon="reply">
    The reply-to on that step is not a valid email address. Correct it or clear
    it.
  </Accordion>

  <Accordion title="A conditional or A/B step is half set up" icon="code-branch">
    An A/B test step needs at least two outgoing branches, a goal, a traffic
    split between **10 and 90** percent, and either a test duration or a
    minimum sample size. A goal set to a custom event also needs the event
    name.
  </Accordion>

  <Accordion title="A wait-for-event step is incomplete" icon="hourglass-half">
    A wait step in wait-for-event mode needs the event name filled in, and it
    needs both of its branches connected: one for the event happening and one
    for the time expiring.
  </Accordion>

  <Accordion title="A list step adds and removes the same list" icon="list-check">
    An Update in list step cannot add a contact to a list and remove them from
    the same list. Pick one side.
  </Accordion>

  <Accordion title="A webhook step points somewhere private" icon="globe">
    A webhook step must post to a public HTTPS address on the default port.
    Internal, private and localhost addresses are refused when you save the
    step and checked again at publish, in case the address was set before this
    rule existed.
  </Accordion>

  <Accordion title="A filter is not valid" icon="filter-circle-xmark">
    An audience filter, exit filter or trigger filter uses a field or operator
    that Senderz cannot evaluate. Reopen the filter and fix the offending
    condition.
  </Accordion>
</AccordionGroup>

### A check that only warns

If some **draft** message steps have no content yet, Senderz tells you how many and offers **Publish anyway**. Drafts are skipped at send time, so this is safe. It exists so you notice a step you meant to finish.

<Warning>
  Draft versus Live on each message step is the single most consequential
  setting in an automation, and it is easy to miss. A draft step is silently
  skipped, the contact moves on to the next step, and nothing anywhere reports
  an error. Check the Live badge on every message step before you publish.
</Warning>

## When a live automation stops being able to send

Edits save automatically a moment after you stop making them, whether the automation is a draft or live. There is no second confirmation, and **editing does not re-run the publish checks**.

That means a live automation can be edited into a state where it enrols people and delivers nothing: set the last live message step back to Draft, delete it, or disconnect it from the trigger.

To catch this, the editor shows a red alert at the top of the canvas while the automation is live and broken:

> This live automation cannot send

The line underneath names the reason, either no trigger or every message step being a draft. Nothing else in the product warns you, because the send path simply skips the step and moves the contact along, exactly as it would for any other draft.

Fix the step, and the alert clears on its own.

## Editing a live automation

You do not need to pause first. Edits apply to the running automation as soon as they save.

What that means for contacts already inside it:

* **A contact who has not reached a step yet gets the new version of it.** Change the copy on step three and everyone still on step one receives the change.
* **A contact parked on a wait resumes into the edited automation** and continues from where they were.
* **A contact parked on a step you delete stops there.** Their journey is marked complete and they receive nothing further from this automation. Because the default re-entry setting is once only, they will not be enrolled again either. If you are restructuring the middle of a live automation, pause it first.
* **Changing a step's channel or template does not re-send** anything already delivered.

## Pausing and resuming

Pause stops the automation enrolling anyone new and stops it delivering. It does not empty it.

Contacts already part-way through stay exactly where they are. Their wait timers do not run out and they are not dropped. When you publish the automation again they continue from the step they were parked on.

Draft, live and paused are the only three states. Archiving or deleting a live automation pauses it in the same action, and restoring one always returns it paused rather than live, so nothing resumes real sends on a single click. See [Automations](/en/messaging/flows) for the archive and delete lifecycle.

## Test run

**Test** in the editor header runs the whole automation once, immediately, for one real contact.

<Steps>
  <Step title="Pick a recipient">
    Choose **Existing contact** and search your contacts, or choose **Email
    address** and type one. If that address is not a contact yet, Senderz opens
    the new contact form so you add it before the test runs. Either way the
    test always runs against a real contact record.
  </Step>

  <Step title="Run it">
    Every step is walked in order with no waiting. The toast tells you how many
    messages were queued and across how many steps.
  </Step>
</Steps>

What a test run does:

| Step                                                                             | In a test run                                                                        |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Email, SMS, Push                                                                 | Sends for real, to that contact                                                      |
| Conditions and A/B splits                                                        | Evaluated against that contact's real profile, so you see the branch they would take |
| Personalization and merge tags                                                   | Rendered from that contact's real data                                               |
| Wait steps                                                                       | Skipped, so the whole automation runs in one go                                      |
| WhatsApp                                                                         | Skipped                                                                              |
| Webhook, Update in list, Update user properties, Team notification, Grant points | Skipped, so no side effects fire                                                     |
| Draft message steps                                                              | Skipped, exactly as they would be live                                               |

Test messages are marked as tests and do not affect your analytics.

<Note>
  A test run is the only way to see a conditional split resolve for a specific
  person before you go live. Pick a contact you know sits on each side of the
  condition and run it twice.
</Note>

## Adding past profiles

A published automation only reacts to events from the moment it went live. **Add past profiles** starts eligible existing contacts at the top of it.

The button sits on the trigger card and is only enabled once the automation is live.

<Steps>
  <Step title="Choose who">
    Profiles from the last 30 days, profiles from the last 90 days, or profiles
    since a date you pick. If the trigger is a list subscription you can
    instead add everyone currently on that list. Contacts added by an earlier
    backfill are excluded.
  </Step>

  <Step title="Estimate">
    Press **Estimate profiles** to see the count before you commit to
    anything.
  </Step>

  <Step title="Confirm">
    The count is rechecked at the moment you confirm. If it has moved since the
    estimate, Senderz refuses and asks you to review the new number, so you
    never approve one figure and enrol a different one.
  </Step>
</Steps>

<Warning>
  This can send real messages. Added profiles enter at the first step and go
  through the automation normally. Audience and exit rules, consent and
  suppression, quiet hours and Shabbat safeguards, and Smart Sending all still
  apply, but if your first step is a live email, people will receive it.
</Warning>

Two things worth knowing:

* **Each added contact keeps the real date of the event that qualified them.** Someone who abandoned a cart three weeks ago is enrolled with that date, not with today's. This matters because exit rules that ask about behaviour "since starting this automation" then measure from the real event. Without it, an "already purchased" exit rule would never fire and buyers would receive abandonment mail.
* **Not every trigger can be backfilled.** Senderz can only add past profiles where it already holds the history. If it cannot, the panel says so plainly rather than adding a partial audience.

Progress shows in the panel while the job runs, and you get a count when it finishes. If it fails you get a notification and no further profiles are added.

## Version history

The clock icon in the editor header opens **Version history**.

* Saves and publishes are kept for **90 days**.
* Select a version to preview the automation it contained, including its step count.
* Each entry shows what happened, when, and who did it: Created, Saved, Published or Restored.

**Restore to draft** replaces the current automation with the selected version. It always comes back as a draft and never goes live automatically, so you review it and publish yourself.

## Reading the numbers

### Per-step performance in the editor

Select a message step in a live or paused automation and the inspector shows a **Performance** card for the **last 30 days**, with a Live or Paused badge and a **View details** link through to the full report.

The rates on it are open rate, click rate, unsubscribe rate and revenue, each calculated against what that step actually sent in the window. Revenue is attributed strict last touch, so an order is credited to the last message the customer engaged with before buying, and never split across several.

Steps also carry small open, click and unsubscribe figures on the canvas itself, so you can scan a sequence without opening each one.

<Note>
  These figures only appear once the automation has been published. A draft has
  no history to report.
</Note>

### The automation report

**Analytics** in the editor header, available once the automation has been published, opens the full report for that automation.

| Tile      | What it counts                                                      |
| --------- | ------------------------------------------------------------------- |
| Enrolled  | Everyone who has ever entered, whatever happened to them afterwards |
| Active    | Still moving through it right now                                   |
| Completed | Reached the end                                                     |
| Converted | Contacts credited with an order, attributed last touch              |
| Revenue   | Value of those orders                                               |

Below the tiles you get a **Conversion rate**, an **Enrollments over time** chart running from the day the automation was created, and an **Active by step** breakdown showing where contacts are currently sitting.

That last one is the fastest way to spot a stuck automation. A large number parked on one step usually means a long wait timer, a condition nobody matches, or a step whose next connector was never drawn.

### Enrollment outcomes

Every contact that enters ends up in one of four states.

<CardGroup cols={2}>
  <Card title="Active" icon="person-walking">
    Still in the automation, either mid-step or waiting on a timer.
  </Card>

  <Card title="Completed" icon="flag-checkered">
    Reached the end of a path. Also what happens when the step they were parked
    on is deleted from the automation.
  </Card>

  <Card title="Exited" icon="door-open">
    Removed early by an exit rule, by unsubscribing or reporting spam, or by
    placing an order in a cart or checkout automation.
  </Card>

  <Card title="Failed" icon="triangle-exclamation">
    Stopped because the journey hit the 200-step ceiling, which only happens if
    the connectors form a loop.
  </Card>
</CardGroup>

All four count toward **Enrolled**. Active and Completed have their own tiles; Exited and Failed do not.

### Workspace-wide analytics

On the **Automations** page, switch the view toggle to **Analytics** for totals across the workspace over a period you choose: last 7, 30 or 90 days, month to date, quarter to date or year to date.

You get active automations, total enrolled, average conversion and revenue generated, plus a ranking of your top automations by enrolled, conversion rate or revenue.

### Exporting

**Options** in the page header exports as CSV or Excel. The export contains exactly the rows and the sort order currently on screen, with these columns:

name, status, trigger, channels, steps, enrolled, conversion rate, revenue, revenue per recipient, email revenue, SMS revenue, and when it was last updated.

A header block at the top of the file records when it was exported, which filters and sort were applied, and two things about the figures:

* The totals are **lifetime** figures for each automation, not limited to the date range you had selected.
* The email and SMS revenue split does use the selected range, and is attributed last touch.

## Troubleshooting a live automation that is not delivering

<AccordionGroup>
  <Accordion title="It enrols people but nothing arrives" icon="inbox">
    Check the Live badge on every message step. A draft step is skipped
    silently. If every message step is a draft, the red health alert appears at
    the top of the canvas.
  </Accordion>

  <Accordion title="Contacts pile up on one step" icon="layer-group">
    Open the report and read Active by step. A long wait timer is normal. A
    conditional split with an undrawn branch is not: when only one outcome is
    wired, the other outcome stops the contact rather than sending them down
    the branch you did draw.
  </Accordion>

  <Accordion title="SMS steps are not sending" icon="comment-sms">
    SMS needs an approved sender ID for the workspace. The Automations list has
    a **Sender problems** tab that collects automations which hit a sender
    setup problem in the last 24 hours. See [Sender
    IDs](/en/deliverability/sender-ids).
  </Accordion>

  <Accordion title="An email step did not hold overnight" icon="moon">
    It is not meant to. The legal Israeli overnight window and Shabbat block
    marketing SMS and push. Marketing email is exempt from that legal block,
    although it still honours your workspace's own quiet-hours setting. See
    [Quiet hours](/en/compliance/quiet-hours).
  </Accordion>

  <Accordion title="Fewer people entered than you expected" icon="filter">
    The audience filter is checked at entry, and again before every action
    step. A contact who stops matching has that step skipped rather than being
    removed, so the automation can look busier than the delivery figures
    suggest.
  </Accordion>
</AccordionGroup>