{
  "id": 5200011,
  "title": "Why I Chose Scheduled SMS Alerts: Cancel Support, Status Polling, App-Owned Templates",
  "url": "https://urgent.news/2026/09/02/why-i-chose-scheduled-sms-alerts-cancel-support-status-polling-app",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-02T23:30:28.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/matsjohansson6547/why-i-chose-scheduled-sms-alerts-cancel-support-status-polling-app-owned-templates-4cd0"
  },
  "original_language": "en",
  "account": "In the world of healthtech, scheduled SMS alerts and reminders pose unique challenges. The key is treating scheduling as a state machine within the application, with possible transitions of canceled, sent, delivered, or failed. This approach allows for clear visibility into the alert's lifecycle and enables appropriate actions based on the current state.\n\nOne crucial aspect is the cancellation of alerts. By tying the cancellation operation to the delivery ID, the system can ensure that the alert is properly halted before it reaches the recipient. This is particularly important in regulated environments where incorrect information can have serious consequences, such as sending a patient to the wrong location.\n\nAnother important consideration is the ownership of templates. Keeping templates in-house, such as in Python code, allows for better control and visibility over the content. This means that pull requests contain the wording, locale, and expiry logic, and the team can easily review and update the templates. It also means that rendering tests and character-count checks are part of the development process, ensuring the alerts are accurate and comply with regulations.\n\nThe cancellation process is handled by calling a specific route before the scheduled send time. After sending, a worker polls the status and events to record the delivery ID and the last observed state. This allows for a clear audit trail, showing what happened after the send and enabling proper handling of any issues that may arise.\n\nIn a test scenario, 38 appointments were moved during a single afternoon. Each reminder carried the clinic's internal appointment ID, locale, and an expiry timestamp. The scheduler created one delivery record per ID, and the cancellation path marked that record before touching the provider. This separation of concerns ensured that late carrier updates couldn't rewrite the audit record and exposed the real cost of polling.\n\nWhen measuring the effects of polling, it became clear that more reads, more queue work, and a delay between an event and an escalation were involved. By measuring these effects directly instead of relying on vendor dashboards, a more accurate understanding of the system's performance was achieved.\n\nIn summary, the key to handling scheduled SMS alerts and reminders in a healthtech backend is to treat scheduling as a state machine, cancel alerts appropriately, keep template ownership in-house, and poll for status and events to maintain a clear audit trail. This approach ensures that the alerts are accurate, compliant, and effectively communicate the necessary information to the users.",
  "summary": "Short answer: I chose an API with scheduled SMS cancellation and polling because health reminders can become wrong between scheduling and delivery; I kept template ownership in the application so every change remains reviewable. That decision is narrower than “which messaging vendor is best?” A vaccination reminder, a lab pickup notice, and a medication alert have different expiry rules. In our…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}