Eine Kampagne über den Logs-Tab diagnostizieren

Open the campaign and click the Logs tab, between Contacts and Learning in the builder. The first thing on the page is a counter row: Total, Errors, and Warnings, with a refresh control at the right.

Read those three as a ratio rather than as absolute numbers. A campaign with a four-figure total, two errors, and a few hundred warnings is normal for a campaign that has been running for a while, because most entries are routine execution notes. The number that should pull your attention is Errors, because that count is usually small and every entry behind it is a thing that did not happen.

Warnings are noisier and mostly repetitive. A campaign that checks its segmentation every hour and finds nothing to do will produce a warning-shaped entry every hour, and hundreds of those add up without anything being wrong.

The refresh control matters because the page is a snapshot. Open the tab, leave it for twenty minutes while you read, and the counters are stale. Refresh before you conclude that an error stopped occurring.

Logs are per campaign. A problem that affects several campaigns has to be checked in each one, and there is no cross-campaign view on this tab.

Under the counters is a From and To date range and a Search events... box. Both narrow the same list.

Set the date range first when you are chasing something you can place in time. If drafts stopped appearing yesterday afternoon, a range around yesterday removes days of routine entries and makes the one that matters findable. When you do not know the time, leave the range wide and use search instead.

Search matches on the event text, so search the way the log writes rather than the way you think about the problem. Searching "draft" finds the drafting entries. Searching "why did nothing send" finds nothing.

Useful search terms in practice are the words that appear in entry titles, such as draft, segmentation, cadence, or email. Start broad and add a second word only if the result list is still too long to read.

The list is ordered newest first, with a relative timestamp on each row: just now, 1h ago, 7h ago. That ordering is what makes the log readable as a story. Scrolling down walks backwards through the campaign's behaviour, and the point where a repeating pattern starts or stops is usually where the answer is.

Two rows of filter chips sit under the search box. The first row is severity: info, warn, error, critical. The second row is category: lifecycle, execution, integration, user-action, ai, system.

The two rows answer different questions. Level answers "how bad is this". Category answers "which part of the system produced it". Combining them is how you get from a thousand entries to the handful worth reading.

A few combinations do most of the work.

• critical alone, with no category filter, shows the entries where something stopped permanently. Start here when a campaign is not sending.
• error plus integration isolates problems reaching an outside service rather than problems in your campaign setup.
• ai alone shows the drafting story: what was drafted, for whom, and under which step.
• lifecycle alone shows the campaign's state changes, which is the fastest way to confirm whether someone paused it.
• user-action alone separates changes a person made from things the system did on its own, which settles most "did someone change this" questions.

Filters combine rather than replace each other, so clear them between investigations. A filter left on from a previous question is the most common reason the log looks empty when it is not.

Each row has a title, a level badge, and a relative time, with a chevron to expand it. Expanding shows the category and a one-line detail.

The most common routine entry on a running campaign is a segmentation check that found nothing to do this tick. Expanded, it reports what happened to the contacts it looked at: how many were rejected as dirty or suppressed, and how many were quarantined as unverified. It carries an INFO badge and it repeats on a regular cadence, once an hour on a typical campaign.

That entry is not a problem on its own. It becomes a problem when it is the only thing in the log for a long stretch, because that means the campaign has been looking for contacts to work and finding none every single time. Read it as a supply signal: the contacts either are not there, are suppressed, or have not passed verification.

Other routine entries include email drafts being created, which name the step they belong to, and cadence variance checks that confirm sending timing is being spread rather than fired in a block.

The reading habit that helps is scanning for change rather than reading every row. A log that repeats the same three entry types on a steady rhythm is a campaign behaving normally. The moment the rhythm changes, a new entry type appears, or a familiar one stops, that timestamp is where to look.

Critical entries look different and carry the reason inline. A permanently failed draft job, for example, expands to state that the email draft failed after a fixed number of attempts and will not be retried, followed by the actual reason the validation failed.

Two parts of that entry matter. "Will not be retried" means the work is finished, not queued, so waiting will not fix it. The reason names the check that blocked it, and that is what points you at the fix.

Draft validation failures usually trace back to one of two places. The first is missing research on the prospect, where the drafting step did not have enough verified facts to write a first-touch email that satisfies the brief. The second is the campaign brief itself, where the constraints in the effective brief are strict enough that no draft could pass. The AI Instructions tab is where both get resolved: check the effective brief pane, and check the conflicts panel under it for instructions that were overridden.

Resist the instinct to loosen every constraint at once. The validation exists to stop a weak email reaching a prospect, and a brief that passes everything is a brief that stopped protecting you. Change the specific constraint the reason names.

When a critical entry appears once and never again, note the timestamp and move on. When it repeats across many contacts, it is a brief or supply problem rather than bad luck on one record.

A campaign is live and nothing has gone out today. Work it in this order rather than guessing.

• Open Logs and read the counter row. If Errors is zero, the campaign is not failing, it is idle, and the cause is supply or state rather than a fault.
• Filter to lifecycle and confirm nobody paused it. This takes ten seconds and rules out the most common answer.
• Filter to critical. If entries appear, read the reason on the newest one and follow it to the AI Instructions tab.
• Clear the filters and look at the routine entries. A long run of segmentation checks finding no contacts means the list is empty, suppressed, or unverified, and the fix is in Contacts rather than here.
• Filter to integration at error level to rule out a mailbox or outside service problem.
• Refresh the page before you conclude anything, since the counters and list are a snapshot.

The log answers what happened and when. It does not answer whether your copy is any good, which is what the Learning tab is for, and it does not answer whether a specific contact was reachable, which is on the contact record. Knowing which surface answers which question is most of the speed.