Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevMauricio03/n8n-whatsapp-ai-agent/llms.txt

Use this file to discover all available pages before exploring further.

Keeping the n8n WhatsApp AI Agent platform healthy requires a small set of routine checks and well-defined processes for the administrative tasks that occur throughout its lifetime. This guide covers the daily review that surfaces problems early, how to read and handle service logs, how to onboard and offboard human agents in Chatwoot, and how to safely make changes to business hours, pricing information, and capacity configuration.

​
Daily review checklist

Run the following checks at the start of each working day. Catching problems early — before customers notice — is far cheaper than reactive incident response.
  • HTTPS reachability — confirm that all public domains (N8N_DOMAIN and CHATWOOT_DOMAIN) respond with a valid certificate and a successful HTTP status code.
  • Container status — verify that every container in the stack is in a running state with no recent restarts.
  • Error growth — scan service logs for error-level messages and confirm there is no unexpected increase compared with the previous day.
  • Disk space — check that the host has sufficient free space for PostgreSQL data growth, Docker logs, and volume writes.
  • WhatsApp send/receive — send a test message to the configured number and confirm the agent responds; confirm outbound sends are working if applicable.
  • Chatwoot background jobs — verify that the Sidekiq worker is processing its queue and not accumulating a backlog.
docker compose --env-file .env -f docker/docker-compose.yml ps
df -h

​
Log monitoring

Each service writes structured logs that are accessible through Docker Compose. Use the --since=1h flag during a daily review to limit output to the past hour; extend the window when investigating a specific incident. 
docker compose --env-file .env -f docker/docker-compose.yml logs --since=1h n8n
docker compose --env-file .env -f docker/docker-compose.yml logs --since=1h chatwoot-rails
docker compose --env-file .env -f docker/docker-compose.yml logs --since=1h chatwoot-sidekiq
docker compose --env-file .env -f docker/docker-compose.yml logs --since=1h caddy
Logs for this stack will contain customer phone numbers, message content, and internal tokens. Do not copy log output into public Slack channels, GitHub issues, support tickets, or any other shared space. If you need to share a log excerpt for debugging, redact all personally identifiable information and credentials before sending.

​
Agent management

​
Onboarding a new human agent

When a new human agent joins the team, follow these steps to provision access with the minimum necessary permissions.
1

Create the Chatwoot account

Create a new user account in Chatwoot with the agent’s business email address. Do not reuse accounts between individuals.
2

Apply the minimum required role

Assign the least-privileged role that allows the agent to handle conversations. Avoid granting administrator access unless it is explicitly required for the agent’s responsibilities.
3

Assign only the required inboxes

Grant the agent access only to the inboxes they will actively work in. Do not assign all inboxes by default.
4

Enable MFA

Enable multi-factor authentication on the account when the feature is available in your Chatwoot version. This protects customer conversation history from unauthorised access.
5

Test Human Handoff

Trigger the Human Handoff flow from a test WhatsApp number and confirm that the conversation is correctly routed to the agent’s inbox in Chatwoot and that the AI stops responding during handoff mode.
6

Record the provisioning

Log the agent’s name, the date of provisioning, the role assigned, the inboxes granted, and the name of the person who approved the access.

​
Offboarding a departing agent

When an agent leaves the team or changes roles, revoke access promptly to prevent unauthorised use of their credentials.
1

Revoke Chatwoot access

Deactivate or delete the agent’s Chatwoot account. Confirm that the account can no longer log in and that their active conversations have been reassigned.
2

Revoke server and n8n access

If the agent had SSH access to the VPS or a user account in n8n, revoke both immediately. Remove their public key from authorized_keys and disable or delete the n8n user account.
3

Rotate shared credentials

If any credentials were shared with the departing agent — including API keys, webhook secrets, or service passwords — rotate them now. Update .env and redeploy the affected services.
4

Review active sessions

Check for any active browser or API sessions associated with the agent’s account and terminate them. Review audit logs if available.
5

Record the offboarding

Log the agent’s name, the date of offboarding, every access point revoked, every credential rotated, and the name of the person who performed the offboarding.

​
Changing business hours

The business-hours logic that determines whether the AI responds or sends an out-of-hours message is implemented in the Code in JavaScript1 node inside the n8n workflow. To change the operating schedule, edit the time boundaries and timezone configuration in that node. After making any change to the business hours logic, verify the following scenarios before activating the workflow in production:
  • Open boundary — send a message at exactly the configured opening time and confirm the AI responds normally.
  • Close boundary — send a message at exactly the configured closing time and confirm the out-of-hours message is sent instead.
  • Weekend — send a message on a Saturday and Sunday and confirm the correct out-of-hours policy is applied.
  • Timezone — confirm that the TZ environment variable in .env matches the timezone used in the Code node logic, and that daylight saving transitions are handled correctly.
  • Public holidays — the main schedule logic does not automatically handle public holidays. Document holiday dates separately and create specific overrides in the workflow when needed.

​
Updating pricing or services information

The workflow uses the INFO_PRECIOS_* environment keys and price image URLs to communicate service and pricing information to customers. These text and image assets must always be consistent — a price listed in a text response must match the image sent alongside it. Treat every pricing update as a versioned release. Before publishing any pricing or services change:
  1. Obtain written approval from the responsible business owner.
  2. Verify that the updated text in the workflow and the updated image assets are consistent with each other.
  3. Test each INFO_PRECIOS_* key by triggering the relevant conversation path on a test number and confirming the response is correct.
  4. Confirm and record the date from which the new pricing is effective.
  5. Ensure the previous image URLs and workflow state are saved so you can roll back quickly if an error is found after publication.

​
Capacity management

Over time, log files, execution records, and Docker image layers accumulate and consume disk space. Review the following on a regular basis:
  • n8n execution retention — configure the execution data pruning settings in n8n to automatically remove old execution records after a defined retention period. Long retention periods with high message volume can cause significant PostgreSQL growth.
  • PostgreSQL and volume size — monitor the size of the n8n, chatwoot, and agent databases and the n8n_data and chatwoot_storage volumes. Set up alerts if any of these approach the available disk capacity.
  • Unused Docker images — periodically remove image layers that are no longer in use with docker image prune. Review what will be deleted before confirming, and ensure you have not removed images you may need for a rollback.
  • Never delete volumes to free space — if disk space is critically low, add more storage to the host or move data to external storage. Deleting a named volume destroys all data it contains and cannot be undone without a backup.

​
Incident priorities

Not every problem requires the same urgency. Use this priority classification to decide how quickly to respond and what to do first. P1 — Immediate action required Incorrect message sends to real customers, any exposure of personal data or credentials, or total platform unavailability. For P1 incidents, deactivate the n8n workflow immediately if continued operation is causing harm. Stopping incorrect output takes priority over maintaining uptime. P2 — Respond within working hours Partial failures affecting audio transcription, query lookups, or the Human Handoff flow. The platform is partially operational but one or more features are degraded. Investigate and resolve during the same business day. P3 — Schedule for normal maintenance Visual inconsistencies in the Chatwoot interface, administrative configuration issues, or minor UX problems that have no impact on customers receiving correct responses.

Build docs developers (and LLMs) love

Get started for freeTalk to us