Workflow refresher

Capture is a very different take on mobile observability. Instead of sending gobs of data from every mobile device to our backend for processing, most of which is never read, incurring high costs and mobile device performance overhead, we couple local storage and real-time control to collect data on the mobile device and only send it to the backend when it is explicitly requested. As we like to say, this provides 1000x the data when you need it, and none when you don’t. The main lever of real-time control is what we call the workflow. A workflow is the visual language for directly querying mobile devices, resulting in a finite state machine that is sent from the backend to every mobile device and tells the device what event sequences to look for, and what to do when that sequence occurs. For example: “Wait for the user to view the check out screen, then if the user leaves the checkout screen or 15s has passed without a checkout, increment a counter and dump a full session with session replay.” Workflows allow encoding very detailed conditions to match on, which allow you to debug extremely detailed cases without the noise of heaps of useless data that do not apply to the case at hand.

Workflow TTLs

Workflows are so powerful and easy to use that it’s easy to generate new data that is super useful, but then as many developers do, forget to clean it up when it is no longer needed. As we said above, it’s a dirty secret in the observability industry that the great majority of data is never read. This has a variety of different implications:

It increases infrastructure ingestion and storage costs. Even though bitdrift is unique in that we do not charge by the amount of data ingested, we still have to model the costs into our per-device pricing. We are incentivized to only ingest data that is actually useful.

It increases resource utilization on each device where the workflows run. Workflows are not free, they do use computational resources, and bandwidth when data is sent. It’s preferable that workflows only run on each device if they are generating useful data.

With today’s feature launch, we are now supplying a default TTL of 30 days for every created workflow. We also keep track of when workflow data is actually read, either via the UI or via API. the TTL resets every time data is read, meaning that data that is consumed will never be shut off. We also have sensible controls that prevent TTL of any data that backs an alert. In the future we will allow administrators to decide on the default TTL of workflows created within an account.

Our focus on useful telemetry

As a company we are committed to not being like every other vendor who enjoys nothing more than charging you for data that is never actually read by a human or machine. Workflow TTLs make sure that precious resources, both on the client and server, are only consumed for a useful purpose. Capture is changing the mobile observability game by adding a control plane and local storage on every mobile device, providing extremely detailed telemetry when you need it, and none when you don’t. If the lack of workflow TTLs was keeping you away, now is the time to give us a try! Interested in learning more? Check out the sandbox or start a free trial to get a hands-on feel for what working with Capture is like or get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!