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.

Retry Triggers

Sensos retries a delivery whenever it is not acknowledged with a 2xx response. This includes:

Any Non-2xx Status Code: Server errors (5xx), rate limiting (429), and client errors such as 400, 401, 403, 404, or 405. Sensos does not distinguish between transient and permanent errors, so fix a misconfigured endpoint or credentials promptly; affected events keep being retried on the schedule below.
Network Failures: Connection timeouts, DNS lookup failures, TCP connection resets, or dropped sockets during transmission.
Authentication Failures: Failure to obtain an access token from your OAuth2 token endpoint.

Events that Sensos intentionally does not deliver (for example, a temperature or humidity log with no valid samples) are not sent and not retried.

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)

Each event is retried independently, so events are not guaranteed to arrive in order. Use the timestamps in the payload to order events.

Disabling or Deleting a Rule

Disabled rule: New events stop being sent within approximately 15 minutes. Deliveries that are already waiting for a retry continue on the schedule above.
Deleted rule: New events stop being sent, and pending retries stop, within approximately 15 minutes.

Terminal State & Redelivery

If all 13 attempts fail, Sensos ceases delivery attempts for that specific event. The event is stored and can be redelivered by Sensos support once your receiver is available again.

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 or a redelivery does not result in duplicate records.
Request Redelivery: If your receiver was unavailable for longer than the retry window, contact Sensos support to have the stored events redelivered.