Posts filter


Today between 11:40-15:00 UTC our webhooks service was partially unavailable. The issue affected only webhooks processing MQTT messages with payloads larger than 512 bytes. Webhooks handling smaller messages continued to operate normally.

The disruption occurred during a gradual rollout of internal MQTT Broker optimizations. While our standard uptime testing procedures include webhook functionality verification, the test cases did not cover processing of large MQTT payloads.

All other platform services remained fully operational during this period. The webhook service has been fully restored to normal operation.

We apologize for any inconvenience this may have caused.


We detected, mitigated the issue and currently are in the process of completely fixing it. During the issue for a few minutes REST API operations towards the telematics hub (/gw/... endpoint) were partially unavailable.


#eu: downtime ended, period: 77 second(s)


#eu: downtime started, error: Failed to perform https://flespi.io/gw/xxx GET request. Usually this indicates either flespi telematics hub REST API overload or when the hub is in the maintenance mode.


#eu: downtime ended, period: 40 second(s)


#eu: downtime started, error: Failed to perform https://flespi.io/gw/xxx GET request. Usually this indicates either flespi telematics hub REST API overload or when the hub is in the maintenance mode.


#eu: downtime ended, period: 65 second(s)


#eu: downtime started, error: Failed to perform https://flespi.io/gw/xxx GET request. Usually this indicates either flespi telematics hub REST API overload or when the hub is in the maintenance mode.


Dear flespi users!

A 15-hour partial disruption of the webhook service occurred on January 15, 2025, due to internal infrastructure reorganization. The incident affected message delivery for some webhooks. Messages within configured Queue TTL were preserved and delivered after service restoration. Messages that exceeded their Queue TTL during the downtime were not recovered.

We apologize for any inconvenience caused. For optimal webhook configuration, we recommend setting appropriate Queue TTL values based on your use case requirements.


Dear flespi users!

Today we are rolling out the update to the flespi analytics system that will allow it to control geofences assigned directly to devices.
During the update each analytics service will totally refresh accumulated device messages cache which may result in extra intervals updates generated for some unstable configurations of calculators.
On top of this we expect additional load in our MQTT Broker bus and telematics messages storage, but most probably you will not notice it.

During the upgrade for some devices (less than 1% of total amount) there can be delays in intervals detection. Such delays usually are less than a minute but in some rare cases this can introduce up to few minutes latency in interval generation.

The upgrade may take up to 2 days (we have 1M devices and track 2M of realtime events) and we will publish a message in the analytics changelog once it is completed and verified: https://forum.flespi.com/d/16-changelog-flespi-analytics

Thanks for your understanding and have a great Tuesday!


Dear flespi users!

The last downtime was caused by sudden routing changes at one of our TIER 1 upstream providers for both datacenters. Routes recalculation took some time, which was the cause of connectivity loss.

Sorry for any inconvenience.


#eu: downtime ended, period: 167 second(s)


#eu: downtime started, error: Failed to perform https://flespi.io GET request. Usually this indicates either flespi eu datacenter network uplink connection problem or when the platform is in the maintenance mode.


Dear Flespi users,

We experienced a brief downtime that affected the Gateway REST API for a short period. However, device connectivity and the MQTT broker were not impacted.

We apologize for any inconvenience caused.


#eu: downtime ended, period: 90 second(s)


#eu: downtime started, error: Failed to perform https://flespi.io/gw/xxx GET request. Usually this indicates either flespi telematics hub REST API overload or when the hub is in the maintenance mode.


Dear Flespi users,

The recent downtime was caused by a high load on our message database system, which resulted from a hardware failure on one of our disks exhibiting non-standard symptoms. Rebalancing this significant load took enough time for our automated test nodes to detect message storage latency. The faulty hardware has been taken offline. We will work on improving detection for such situations in the future.

We apologize for any inconvenience caused.


#eu: downtime ended, period: 21 second(s)


#eu: downtime started, error: Simulated telematics device connected to the channel, sent the packet with message, but channel didn't replied to it. Usually this indicates the problem with flespi Telematics Gateway.


#eu: downtime ended, period: 56 second(s)

20 last posts shown.