Data Delivery Retry Policy

Sensos implements an automated retry policy for outbound data delivery (webhooks) to ensure reliable data transmission even during upstream network partitions, temporary receiver downtime, or server maintenance.

The policy uses an exponential backoff algorithm that progressively increases the delay between retry attempts, protecting your receiving infrastructure from being overwhelmed while preventing data loss.

Delivery Acknowledgment Requirements

Success Status Code: Your webhook receiver must return an HTTP 2xx status code (200 OK, 202 Accepted, or 204 No Content) to acknowledge successful delivery.
Timeout Window: The receiving endpoint must return its HTTP response within 10 seconds. Requests exceeding 10 seconds are treated as timed out and scheduled for retry.

Failure Classification & Retry Triggers

Sensos distinguishes between transient communication failures and permanent client-side errors:

Transient Failures (Retried)

Sensos automatically schedules a retry when encountering:

Server Errors: HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
Rate Limiting: HTTP 429 Too Many Requests.
Network Failures: Connection timeouts, DNS lookup failures, TCP connection resets, or dropped sockets during transmission.

Permanent Failures (Not Retried)

Delivery attempts that fail due to client-side configuration errors are not retried, as re-sending an identical payload will not resolve the underlying issue:

HTTP 400 Bad Request (payload schema rejected by receiving endpoint)
HTTP 401 Unauthorized / 403 Forbidden (invalid authentication header or expired credentials)
HTTP 404 Not Found (invalid or decommissioned webhook URL)
HTTP 405 Method Not Allowed

Retry Schedule & Exponential Backoff

The delay between successive retry attempts is calculated using the following formula:

$$\text{Delay} = 2^{(\text{retry count})} \times 30\text{seconds}$$

Failed deliveries are retried up to 13 attempts (1 initial attempt + 12 retries) spanning approximately 34 hours:

Attempt Number	Retry Number	Delay (seconds)	Delay (human-readable)	Accumulated Delay
1	0 (Initial)	0s	Immediate	0s (0 minutes)
2	1	30s	30 seconds	30s (0.5 minutes)
3	2	60s	1 minute	90s (1.5 minutes)
4	3	120s	2 minutes	210s (3.5 minutes)
5	4	240s	4 minutes	450s (7.5 minutes)
6	5	480s	8 minutes	930s (15.5 minutes)
7	6	960s	16 minutes	1,890s (31.5 minutes)
8	7	1,920s	32 minutes	3,810s (~1.06 hours)
9	8	3,840s	~1.07 hours	7,650s (~2.13 hours)
10	9	7,680s	~2.13 hours	15,330s (~4.26 hours)
11	10	15,360s	~4.27 hours	30,690s (~8.52 hours)
12	11	30,720s	~8.53 hours	61,410s (~17.06 hours)
13	12	61,440s	~17.07 hours	122,850s (~34.13 hours)

Terminal State & Dead-Letter Handling

If all 13 attempts fail, Sensos ceases delivery attempts for that specific event. The event is permanently marked as Failed in the internal dispatch audit logs.

To avoid missing critical data during prolonged receiver outages:

Monitor Receiver Health: Ensure your webhook endpoints have automated health checks and alerting.
Idempotency: Webhook events carry unique identifiers (messageId for device reports, logId for temperature/humidity logs, id for alerts). Always de-duplicate incoming payloads using these keys so that receiving a delayed retry does not result in duplicate records.
REST Polling Fallback: In the event of an extended system outage, missing telemetry can be retrieved via the Sensos REST API once your systems are restored.