Deeper Observability for Your Third-Party Services with Taskless

There are finally third party services worth integrating into products and introducing external dependencies; this is a good thing. As developers, we prefer to focus on the product problems, not build the world's 4,238th connection to UPS's tracking system. But with this increase in the footprint of external services within our application stack comes a new set of challenges around observability and monitoring.

The problem with third party services is that service issues are more than just the error codes reported. And that "one size fits all" error reporting is where Application Performance Monitoring (APM) and exception tools stop. This can lead to loss of key data; for example, Stripe can include doc and log links that can speed up the triage of issues in addition to the standard HTTP error code, but it is not standard to pick this valuable data up at the time of failure.

For another example, X.com recently made the "likes" of profiles private data. Calls to the X API still worked but as a result of the change, these requests returned empty data inside of a 200 response. Because there was no error code, APM and exception tools reported no issue with the response. Downstream systems using the "likes" data broke in unexpected ways, and there was no traceable information on why in the logs.

These unexpected changes to data coming from an external source outside your control are why we built the @taskless/observe Pack - it's one of the many Packs you can add to Taskless, providing deeper observability for the services you depend on.

Flexible Control and Comprehensive Monitoring

First, like all other Packs, the Observe Pack can be configured to watch as many (or as few) URLs as you'd like. Maybe you're only concerned about the X API, or there's one payments provider you keep seeing in tickets raised by customers. Control begins with choosing what you want to watch, and deciding how much watching you want to do. This mix of filtering and sampling allows you to focus your observability efforts on the highest impact services within your product.

To start using @taskless/observe is as easy as adding the Taskless API key to your config, no changes to deployments needed:

TASKLESS_API_KEY="your api key" node --import="@taskless/loader" start.js

Just like any other Pack, the Observe Pack is configured in the Taskless dashboard and brought into your application on your configuration's update interval. The Pack provides comprehensive tracking capabilities, including response code, duration monitoring, and attribute tracking. By analyzing common error payloads, it can provide additional context beyond just the error code, giving you visibility into the real reason your request is failing. This extra layer of insight can be invaluable when troubleshooting issues because the failure state is now known, and your resolution process can start there rather than replaying the call and hoping it errors in the same way.

Actionable Insights and Seamless Integration

Taskless dashboards are designed to be actionable by default, and the Observe Pack's default dashboard includes:

• Failure rates to answer "is this failure new?"
• 7 day week over week attribute tracking to spot anomalies and answer "did something change out from under us?"
• Recent API error logs from the provider on failed requests to answer "is my third party service telling me what's wrong?"

You can also build your own custom dashboards to quickly display the data important to your process. And all Taskless data is queryable by attribute for building insights or exportable to your existing incident management tools for a seamless workflow.

Continuous Improvement Over Time

The key benefits of Taskless' Pack design is that your observability setup will improve over time. As Taskless learns more about the endpoints you call, it can begin to recommend specialized Packs with logging details optimized for the specific services you use.

To illustrate, consider an API that relies on usage-based limits. When Taskless detects a correlation between certain response headers and errors, it can proactively recommend new Packs and suggest solutions to keep your incident rate low. This could involve tracking specific headers that indicate your proximity to the usage limit or suggesting strategies in the dashboard to optimize your API consumption.

Try It Out Today

The @taskless/observe pack is available through taskless.io, but even if you're not in our Early Access, you can still run the Taskless Client Library (OSS, Apache 2.0) and generate NDJSON logs that work with your favorite logging and monitoring systems. The local client cannot be dynamic nor reactive, but it can give you a head start the next time an API causes an outage for your team.

As we identify trends with popular APIs, we'll update the built-in packs for the OSS client too. We're on a mission to eliminate the risk of bringing on third party services.

Head over to the Taskless GitHub repo to get started, and in less than an hour be on your way to deep observability of your third-party services.