Everything Was Green. One Endpoint Was Still Breaking Your System.

Your dashboard looks good.

No alerts.
No downtime.
No major errors.

Everything is green.

But something is wrong.

Users are complaining.

Payments are failing.
Requests are timing out.
Some actions just don’t work.

You check your logs.

Nothing obvious.

You check your provider.

Status: Operational

So where’s the problem?

The hidden issue

Not everything is broken.

Just one endpoint.

Maybe it’s:

• /charges
• /verify
• /send

Everything else works fine.

So the provider looks healthy.

But that one endpoint…

is failing your users.

Why you didn’t see it

Most monitoring works at a high level:

• Is the provider up?
• Is the API responding?

And the answer is:

Yes.

But that’s not enough.

Because your system doesn’t use “the provider” in the abstract.

It uses specific endpoints.

What you actually need

Not:

“Is the provider working?”

But:

“Is this exact endpoint working properly?”

Using OutboundIQ (Laravel example)

With OutboundIQ, endpointStatus() checks one endpoint pattern you’ve modeled in your project — not a second “path” argument. You pass the endpoint slug from the dashboard (OutboundIQ builds slugs from provider + HTTP method + path, e.g. something like stripe-post-v1-charges for POST /v1/charges). See the endpointStatus() docs for the full response shape.

The method returns an array (or null if the call fails). Use decision.usable (and optionally decision.action) — the same pattern as providerStatus(), not a $status->isHealthy() helper.

use OutboundIQ\Laravel\Facades\OutboundIQ;

public function charge(User $user, Money $amount): void
{
    // Slug from OutboundIQ → Endpoints (e.g. encodes POST https://api.stripe.com/v1/charges)
    $status = OutboundIQ::endpointStatus('stripe-post-v1-charges');

    if ($status && $status['decision']['usable']) {
        Payment::charge($user, $amount);
    } else {
        BackupPayment::charge($user, $amount);
    }
}

Replace 'stripe-post-v1-charges' with the slug for your critical route (charges, verify, send, etc.).

What’s happening here?

OutboundIQ evaluates that endpoint using real signals — success rate, latency, errors, stability — tied to the outbound calls you actually track.

Not “the whole provider” at once.
The route your system depends on.

If you only have the path in mind

Find the matching row in the OutboundIQ Endpoints UI and copy its slug — you don’t pass ('/charges', …) as a separate string to endpointStatus(); the slug already reflects method + path pattern.

What this changes

Instead of guessing:

• You see which endpoint pattern is unhealthy
• You avoid sending traffic there or you tighten retries
• You switch or degrade early — even when everything else looks fine

The simple truth

Your provider can be healthy.

And still break your system.

Because:

One endpoint is all it takes.

Everything was green — you were just looking at the wrong level.

Take the next step

• Full reference: endpointStatus() in the docs
• Context: API Intelligence overview
• Foundations: Getting Started with API Monitoring