SigSpan is a fully serverless, single-region deployment on AWS. This page walks through the path an alert takes from inbound email to outbound SMS, and the operational surfaces around that path.
Every alert SigSpan delivers follows the same four-stage path. The whole thing typically completes in under three seconds.
Amazon SES
Inbound monitoring alerts hit a per-tenant SigSpan address. Amazon SES handles receipt, spam filtering, DKIM and SPF validation, and TLS termination from the sending MTA.
AWS Lambda
A Lambda function parses the email, extracts the alert content, applies per-tenant routing rules, and resolves the on-call recipient phone numbers.
DynamoDB + AWS KMS
Tenant configuration, recipient phone numbers, consent records, and the message audit log all live in DynamoDB. Every table is encrypted at rest with AWS KMS-managed keys. Records are scoped by tenant on the partition key.
Amazon SNS
The parsed alert is dispatched to recipients via Amazon SNS. Suppression-list checks (STOP, UNSUBSCRIBE) and per-tenant rate limits are applied immediately before dispatch. Carrier response codes are persisted to the audit log.
The services that sit alongside the message path — what protects it, watches it, and bills for it.
AWS WAF sits in front of the customer-facing API for baseline DDoS and request-shape protection. All credentials — SMTP, third-party API keys, JWT signing keys — are stored in AWS Secrets Manager and accessed at runtime by Lambda execution roles with least-privilege IAM policies.
All Lambda invocations, SES receipts, SNS dispatches, and application-level events stream into Amazon CloudWatch. The per-message audit log is retained for 30 days by default and can be extended on a per-tenant basis. Internal alerting is wired against CloudWatch metrics.
Usage is metered at the dispatch path: every successful SMS dispatch is recorded against the tenant's Stripe subscription. There are no monthly platform fees — invoicing reflects only metered usage. Pricing details →
It is worth being explicit about the parts of the platform we have not built yet, so you can decide whether they matter for your use case.
The principle here is the same as the rest of this page: be specific. A long list of vague claims helps no one; a short list of concrete capabilities and concrete gaps lets you make an informed call.
Last reviewed: 2026-05-17. This page is reviewed at least quarterly; service names are stable, but specific implementation details may shift between reviews.