Disable Source / HealthCheck?

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, , ,
1

Hey everyone,

I’m encountering an issue where I need to disable the automatic health check on a source in SailPoint Identity Security Cloud (ISC), or at least temporarily disable the source from reaching its endpoint.

I’ve tried updating the source JSON by setting the healthcheckDisabled value to true within the slpt-source-diagnostics configuration, but it seems to get reset back to false automatically.

Currently, our workaround is to intentionally change the URL of the source so the health check fails, but this isn’t an ideal solution. Is there a proper way to disable the health check or the entire source itself that I’m missing?

Any ideas or suggestions would be a great help! Thanks!

2

Hi @trettkowski

I tried looking into the docs and community discussions and also SailPoint ISC Documents that are present online but I couldn’t find a supported “turn off health check entirely” toggle in Identity Security Cloud (ISC). The fact that your healthcheckDisabled flag gets reset suggests the system either ignores it or enforces a default override somewhere.

Also update-source api does not have any option of this kind.

3

Just curious, what’s the underlying reason why one would like the health check to be disabled?

4

Hey @mcheek,

Right now, simultaneous health checks from two tenants are hitting the server and causing an account lockout. We don’t seem to have the option to control the health check timing, so disabling the source/health check seems like the easiest immediate fix.

5

Howdy folks. We are in the same boat with a custom Web Services connector. Hopefully someone knows how to disable the healthCheck pings.

6

bump bump megabump. looking for same solution, having same issue as OP.

7

Have you attempted to update the healthCheckTimeout attribute, such as configuring it with a minimal value ?
Just a rough guess on my end.

8

Hi @Kevin,

Even we have the following requirement but were not able to achieve it. We did raise a SailPoint ticket but were told that this is not possible.

9

I’d recommend first trying to pause the source directly through the admin console, which should stop the health check without the need for workarounds. If you’re managing it programmatically, using SailPoint’s API might give you more control over the configuration.

10

I’m curious, which API endpoint would you use for that?

11

I’m also not aware of a pause option on the source. @nickmallen is there an endpoint you’re using for that?

12

Hi Tyler Rettkowski

You can use the API’s partial update (PATCH /v3/sources/{id}) to set editable fields, but make sure health check control isn’t exposed publicly.

13

Hi @nickmallen,

Have you tried using this API ?
It seems like the configuration is getting overwritten automatically.

14

Hey @trettkowski — I read through the full thread and the pattern is pretty clear:

  • Setting healthcheckDisabled=true under slpt-source-diagnostics gets auto-reset.

  • There’s no supported UI toggle (no “pause source” button for this behavior).

  • The public PATCH /v3/sources/{id} endpoint can update some editable fields, but health-check on/off is not exposed as a supported, persistent control, so trying to “force” it via JSON won’t stick.

So if the goal is “stop ISC from pinging my endpoint,” today the answer is: you can’t truly disable health checks via supported controls.

What does work (mitigation that avoids lockouts)

Based on OP’s root cause (two tenants pinging the same endpoint and locking the account), I’d treat this as an endpoint/service-account design issue rather than a SailPoint toggle issue:

  1. Never share the same credential across tenants

    • Create one connector/service account per tenant.

    • This instantly eliminates cross-tenant “bad password” storms

  2. Make that account “non-human” from an auth-policy standpoint

    • Exempt it from MFA / Conditional Access rules.

    • If your directory/app supports it, exempt it from lockout or raise the lockout threshold specifically for that service account.

  3. If you control the endpoint, add a light “health-check safe path”

    • Health checks are repetitive and predictable. If you can detect them (same user-agent / same auth header / same path), route them to a cheap, non-locking validation.

    • If the endpoint is behind an API gateway, rate-limit that route and allowlist SailPoint egress IPs.

  4. If this is a Web Services connector, prefer OAuth client credentials if the API supports it

    • This avoids password-based lockouts entirely
15

This appears to be an ongoing idea that has not been implemented in ISC even though it’s in IIQ. If you stumble upon this thread, please upvote the ideas below so SailPoint can prioritize.

Ideas Submissions:

https://ideas.sailpoint.com/ideas/GOV-I-1964

https://ideas.sailpoint.com/ideas/GOV-I-3920

16

UPDATE!

There is a connector attribute you can patch into the source called “health_check_disabled” and when set to true seems to stop the frequent pings connectors do to the source. I think combining this with turning off scheduled account/entitlement aggregations as well as disabling provisioning with “enableProvisioningFeature” set to false, will effectively disable the source. I’m still testing this, but it seems much more promising than changing the URL or credentials.

@Crimson3708 @RAKGDS , pinging you both since you seem to need this requirement.