WhatsApp Watchdog Cron

This document explores the whatsapp-watchdog cron job, a daily maintenance task designed to ensure the reliability of WhatsApp message delivery through the Evolution API. While the core functionality is minimal, its role in maintaining communication integrity is critical—especially given the 19 pre-defined message templates and strict rate limits in place.

Overview

The cron system in Odys is structured around two scheduled tasks defined in vercel.json: one for appointment reminders at 8 AM, and the whatsapp-watchdog at 9 AM daily. This timing suggests a deliberate sequence—first handling time-sensitive user notifications, then verifying the health of the messaging infrastructure. The watchdog targets /api/cron/whatsapp-watchdog, which likely interfaces with a broader WhatsApp integration that includes webhook handling (/api/whatsapp/webhook) and templated messaging.

The cron handler is expected to reside within the src/app/api/cron/whatsapp-watchdog directory. However, the specific handler file (e.g., route.ts) was not accessible for review, preventing a deep dive into its implementation. This means the actual logic—whether it performs active health checks, logs results, or triggers alerts—cannot be verified from available data.

Despite this limitation, the watchdog's existence aligns with the system’s reliance on WhatsApp as a primary communication channel. With 19 message templates—ranging from booking confirmations to no-show alerts—and a rate-limited WhatsApp endpoint (10 requests per minute), ensuring API availability is essential to prevent missed client interactions.

Design decisions

The watchdog’s schedule—0 9 * * *—positions it just after the reminder cron, implying a dependency: once reminders are dispatched, the system checks whether the messaging pipeline remains functional. This separation of concerns (sending vs. monitoring) keeps responsibilities distinct and debuggable.

The use of Vercel’s cron feature, declared in vercel.json, avoids third-party scheduling services, reducing complexity. However, it also means the cron runs in a serverless environment, where execution duration and network stability are constrained. The absence of error alerts or retry logic in the manifest suggests failure detection may be passive.

Notably, the /api/cron/whatsapp-watchdog route is not listed in the apiRoutes fact, which could indicate it's either dynamically registered or excluded from public documentation—a potential oversight in observability.

Potential improvements

1. Add health-check validation logic
   The current implementation (if empty or minimal) should be enhanced to actively verify the Evolution API by making a test request, such as fetching instance info or sending a dummy message to a known number. Without actual API interaction, "watchdog" is a misnomer.

2. Integrate with notification system
   If the watchdog detects failure, it should trigger an alert via the existing notifications table and /api/notifications. For example, inserting a high-priority record with recipientType: 'admin' would ensure staff are informed—currently, failures may go unnoticed.

3. Log status to a dedicated table
   Introduce a cron_logs or system_health table to record execution results of whatsapp-watchdog. This would enable auditing and trend analysis, especially useful given the lack of visibility into cron outcomes in serverless environments.

References

• vercel.json
• /api/cron/whatsapp-watchdog
• /api/whatsapp/webhook
• whatsapp/messageTemplates (implied by template count and names)