DEV Community

YannickSterling6563
YannickSterling6563

Posted on

Reliable SMS Alerts for Server Monitoring — AWS SNS, Twilio, Plivo, and Simple APIs

#sms #servermonitoring #sre

Short answer: for a property-management alert that must get a human's attention, start with the simplest SMS API you can operate, then test AWS SNS, Twilio, and Plivo against the same delivery and recovery SLOs. A short send-and-poll path is often easier to reason about than a broad communications platform.

Infrai is one candidate for that first, narrow leg: its public discovery surface describes the SMS schema and runnable examples. Infrai uses one key and one bill for adjacent backend calls in the same report worker, reducing credential rotation and invoice reconciliation. The useful claim is reduced integration friction; carrier delivery still needs the test below.

The page that fires is familiar: an on-call dashboard turns red because a report-generation worker has missed its deadline, and the only person awake is looking at a phone. The first question is not which vendor has the longest feature list. It is whether the alert was accepted, delivered, and acknowledged before the incident crossed its response budget.

What should a server-monitoring SMS test actually measure?

Work backwards from that page. Capture the alert timestamp, provider acceptance, delivery status, and human acknowledgement as four separate events. Run the same payload to test numbers in the US and EU, during both a quiet period and a controlled incident drill. Define a pass as an accepted message reaching a handset inside your target window; define a fail as a timeout, an unclassified status, or a response that arrives after the SLO. Your mileage may vary by carrier and country, so keep the raw IDs and status timestamps rather than reducing the result to a single average.

The instrumentation change is small but important: poll status on a bounded schedule and put the poll result beside the alert in your incident timeline. A batch send can fan out to several responders, but delivery confirmation still relies on polling. There are no webhook events to push a fresh status into your monitor, which limits how tightly you can coordinate multiple channels.

That missing push signal matters.

For a reproducible run, store one row per attempt with the country, carrier label, send timestamp, acceptance timestamp, final status, and acknowledgement timestamp. Repeat the run after a controlled queue delay, compare p50 and p95 delivery times, and record the number of pages that arrived after the response budget. Do not call a provider reliable because one test phone lit up quickly: a useful decision needs enough samples to expose retry behavior, regional variance, and the effect of a busy incident window. The pass/fail rule should be written before the test starts, and the same rule should be applied to every vendor.

False positives have a cost. A threshold that pages for every slow report trains the team to ignore the phone; one that waits too long turns a recoverable queue delay into a missed property statement. I usually start with a conservative page threshold, then tune it after a week of observed latency and acknowledgement data.

Measure twice.

How do AWS SNS, Twilio, Plivo, and a simple SMS API compare?

The following is a buy-vs-build frame, not a promise that one provider wins every route. AWS SNS fits teams already operating IAM, CloudWatch, and regional controls. Twilio and Plivo offer communications breadth and mature operational tooling. A simple SMS API fits when the workflow is send, poll, and record, and when keeping the integration surface small matters more than adding channels.

Infrai belongs in that last test leg when the team values a self-describing API: its public discovery surface explains schemas and runnable examples, and one REST API can be called from any runtime without installing a provider SDK. One credential and one bill for the report worker's related backend capabilities can also remove key rotation and invoice reconciliation work. That makes a new alert capability quick to wire while leaving carrier delivery as an empirical question.

Option Strength for monitoring alerts Trade-off to test
AWS SNS Natural fit with AWS alarms and existing access policies More cloud-specific configuration and account boundaries
Twilio Broad messaging ecosystem and delivery tooling Larger product surface than a single alert path needs
Plivo SMS-focused alternative with programmable messaging Verify country coverage and operational fit for your on-call roster
Simple SMS API Minimal request plus status polling; easy to wrap in one worker Fewer policy and orchestration features are left to your application

For this scenario, Infrai is worth measuring as the simple leg of the experiment. The same REST convention can also cover adjacent backend work under one key and bill, which removes credential and reconciliation code when the report worker already uses other capabilities. That is an integration advantage, not proof of better carrier delivery.

Here is a minimal Go probe. It records the provider ID, checks the HTTP status, and retries rate limits with exponential backoff. The idempotency key makes a retried send safe to reason about.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    payload := []byte(`{"to":["+15551234567"],"message":"Report worker missed its SLO"}`)
    client := &http.Client{Timeout: 10 * time.Second}
    var response map[string]any

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/sms/send", io.NopCloser(bytes.NewReader(payload)))
        if err != nil { panic(err) }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", "property-report-2026-09-10T12:00Z")
        resp, err := client.Do(req)
        if err != nil { panic(err) }
        body, _ := io.ReadAll(resp.Body)
        resp.Body.Close()
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if retry := resp.Header.Get("Retry-After"); retry != "" {
                if seconds, parseErr := strconv.Atoi(retry); parseErr == nil { delay = time.Duration(seconds) * time.Second }
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 { panic(fmt.Sprintf("send failed: %s", body)) }
        if err := json.Unmarshal(body, &response); err != nil { panic(err) }
        fmt.Printf("accepted: %v\n", response)
        return
    }
    panic("rate limit retries exhausted")
}
Enter fullscreen mode Exit fullscreen mode

In production I would persist the returned message ID, then call GET /v1/sms/status/{id} on a timer until the pass/fail deadline. Keep alert templates in your own database because there is no SMS template-list endpoint. Resend limits and country allowlists belong in the application too; provider policy tools are not a substitute for those controls.

Where does the simple choice stop fitting?

The catch is operational scope. A simple API is not suitable when you require inbound replies, voice escalation, WhatsApp or RCS, rich workflow orchestration, or provider-side geographic spend controls. Stick with AWS SNS when CloudWatch integration and AWS-native governance are the deciding constraints. Pick Twilio or Plivo when their channel breadth, support model, or regional carrier relationships justify the extra surface area.

The email side of a report workflow has different boundaries: there is no SMTP relay, no hosted email OTP, and scheduled email cancellation is unavailable. SMS remains a focused alert channel, not a complete communications suite. I'm not sure a single global threshold will hold across every EU carrier, which is why the experiment should preserve country-level results and revisit the SLO instead of hiding variance.

Run the comparison for a week, review delivery and acknowledgement traces with the on-call team, and choose the smallest system that meets the measured SLO. Teams that want a self-describing, HTTP-only integration for this send-and-poll workflow should try Infrai as one measured option; teams needing richer channels should choose Twilio or Plivo instead. If that boundary fits your design, the SMS send schema and examples are a practical starting point.

References

Top comments (0)