SAP BTP Cockpit issues: five problems and how to fix them

If SAP BTP Cockpit is throwing errors at you, it is probably one of five things. A 401 from a service key is almost always the OAuth request, not the credentials. An Internal Server Error on Integration Suite usually means missing role collections or a stale session. Dead links come from boosters set up before the subaccount changed. CAP destination failures are usually a name mismatch or a missing binding. And an app that worked yesterday on a trial account may have lost its database overnight. This guide is for developers and integration consultants working in Cloud Foundry subaccounts. The triage table below tells you what to check first.

The first time I saw the red error banner in SAP BTP Cockpit, I assumed I had done something wrong. Wrong link, expired session.

After the third or fourth time, it was clear it was not just me.

Over the next few weeks I kept a notebook and wrote down every time something broke. Internal Server Errors opening Integration Suite. Destinations that looked valid and refused to connect. Apps that worked yesterday and hung today. Patterns emerged. Few of them were documented anywhere useful, and the Cockpit itself gives you almost nothing to work with.

Symptom	Most likely cause	Check first
401 Unauthorized calling an API with a service key	Wrong grant type, token URL or missing authorities	Decode the token and read aud and scope
Internal Server Error opening Integration Suite	Missing role collections or stale session	Role collections on your user, then a full log-out
Booster or tile opens a blank or wrong page	Subaccount changed after the booster ran	Navigate via the Cockpit tree instead
CAP app: "destination not found" or auth errors	Name mismatch, missing binding, wrong OData kind	cds.requires and xs-app.json against the Cockpit name
App worked yesterday, hangs today (trial)	HANA Cloud instance stopped overnight	Database instance status in SAP HANA Cloud Central

Cloud Foundry, Kyma and the ABAP environment run on SAP's multi-cloud foundation, which has been the default for new customers since 2020. The older Neo environment gets security and compliance updates only, and SAP has set its sunset for 31 December 2028. Nearly every issue below is a Cloud Foundry issue.

Two renames still confuse people reading older guides. SAP Launchpad service became SAP Build Work Zone, standard edition, in January 2023. And many tiles and boosters were rebuilt as SAP Build grew, so screenshots from 2022 often no longer match what you see.

On RISE with SAP, BTP usually arrives as a credit-based entitlement inside the contract. The Cockpit is the same. What differs is who in your organisation controls the global account, so find that person before you need a new entitlement.

You create a service instance, generate a service key, copy the client ID and secret into Postman, add the token URL and send the request. 401. No detail.

You copy the secret again. Still fails. The service is fine. The OAuth flow is not.

What to check, in order:

1. Grant type. Technical access to most BTP service APIs uses client_credentials. Set it explicitly in Postman. Do not trust the default.
2. Token URL. Take it from the service key. Some keys give a tokenurl; others give the XSUAA url, to which you append /oauth/token. Never borrow one from another subaccount.
3. Headers. For a direct token call, send Content-Type: application/x-www-form-urlencoded and Authorization: Basic <base64(clientid:clientsecret)>.
4. Authorities. With client credentials, the token only carries the scopes granted to that service instance. If the API needs a role the instance does not have, you still get a token, and the API still says no. Fix it in the instance parameters (for example, the roles on an Integration Suite API plan instance), not in the request.
5. Audience. If you have a token and the API rejects it, decode the token and read the aud claim. If it does not match the API you are calling, you are using a key from the wrong service instance.

You open Integration Suite and get a red "Internal Server Error" banner. No log. Reload, different browser, same result.

It usually happens after the service has been left unused for a while: opened in the morning, left for a few hours, used again later. SAP's community threads and knowledge base point to two usual causes: missing role collections and stale sessions.

What usually resolves it:

1. Check role collections. Your user needs Integration_Provisioner to set up the tenant, and the relevant PI_ role collections (administrator, integration developer, business expert) to work in it. Assign them in the subaccount under Security.
2. Log out completely. Role changes only reach your session after a fresh login. Close every BTP and Integration Suite tab, sign out, then sign back in.
3. Clear cookies for the BTP domains if the error survives a fresh login. A stale session cookie can outlive the session.
4. Use one Cockpit session. Several tabs or browser profiles on the same subaccount cause session conflicts that look exactly like this error.

The real problem is visibility. The Cockpit tells you nothing about what failed, so you end up guessing. Work through the list in order instead. For a wider view of why integration programmes stall, see my piece on SAP Integration Suite delivery delays.

You click "Go to Application" and get a blank screen, a generic landing page or a redirect that makes no sense.

It follows patterns:

1. Booster links break when the subaccount setup changes after the booster ran. The redirect points somewhere that no longer exists.
2. Integration Suite tiles sometimes work, sometimes error, sometimes time out, usually for the session reasons above.
3. SAP Build Work Zone links show "connection denied" when the subscription exists but your user lacks the role collection for the site.
4. Multiple tabs or browser profiles open links in expired contexts.

What works: navigate through the Cockpit tree (subaccount, then Services, then Instances and Subscriptions), and bookmark the direct URLs for Integration Suite, destinations and Work Zone. Use one session in a clean browser profile. When a link fails every third time, you stop trusting the platform and start building workarounds. Bookmarks are the cheapest workaround there is. If you are still finding your way around, my BTP Cockpit walkthrough covers the basic navigation.

You deploy a CAP app, configure a destination in the Cockpit, and requests still fail with "destination not found" or authentication errors. The destination is listed. The app is running. The error messages point nowhere useful.

SAP's CAP documentation is clear on how this should be wired: the remote service is declared under cds.requires in package.json (or .cdsrc.json) with a kind, and the destination name goes under credentials.destination. The app also needs bindings to both the Destination service and XSUAA. Most failures are a break somewhere in that chain.

1. 01cds.requiresDeclares the remote service, its kind and the destination name
2. 02Production profileHolds the destination credentials after deployment
3. 03Service bindingsThe app is bound to Destination and XSUAA
4. 04Destination in the CockpitSame name as in cds.requires and xs-app.json, case included
5. 05Remote serviceodata-v2 for a V2 service, odata for V4

Requests reach the remote service

Symptom	Fix
Destination listed but the app cannot find it	Compare the name in cds.requires and in xs-app.json routes with the Cockpit, character for character, including case
Works locally, fails after deployment	Check the [production] profile actually holds the destination credentials, and that the app is bound to Destination and XSUAA
Remote OData V2 service returns errors	Set kind to odata-v2 for a V2 service and odata for V4. Use V4 wherever both sides allow it
A UI5 app needs V2 but your CAP service is V4	Add the @cap-js-community/odata-v2-adapter plugin. The older @sap/cds-odata-v2-adapter-proxy is deprecated
Authentication fails with valid credentials	Start with OAuth2ClientCredentials or BasicAuthentication. Only use SAML or principal propagation when the scenario needs it
Not sure the target is reachable at all	Use "Check Connection" on the destination in the Cockpit before you debug the app

Teams that handle this well keep a short destination checklist per app. Not because the setup is complex. Because one wrong assumption about name, binding or OData kind fails silently and takes far longer to find than to prevent.

A CAP app that worked yesterday now hangs. No error. The Cockpit shows it running. You restart it. Nothing.

Check the database first. SAP's own HANA Cloud trial tutorial states that free-tier instances are stopped every night and must be restarted each day you work. The trial account itself lasts up to 90 days if you log in regularly. Your app is fine. Its database is asleep.

What helps:

1. Restart the HANA Cloud instance from SAP HANA Cloud Central before you start debugging code.
2. Use the CLI (cf apps, cf services) to see memory and service usage. The Cockpit UI shows far less.
3. Delete unused service instances before creating new ones. Trial quotas apply to the whole account, not just one app.
4. Keep demo and test workloads in separate subaccounts.

If you need more than one app and database running reliably, or stable uptime for demos, move to a productive account. Free-tier plans in a productive account can be upgraded to paid without losing your work, which a trial account cannot.

Why do I get a 401 error with SAP BTP service key credentials even when they look correct?

Almost always the OAuth request, not the credentials. The usual causes are the wrong grant type (use client_credentials for technical access), a token URL that does not match the service key, or wrong headers on the token call.

If you get a token and the API still rejects it, decode it. Check the aud claim matches the API, and check the scopes. With client credentials, scopes come from the authorities granted to the service instance, so fix missing roles in the instance parameters.

What causes Internal Server Errors when opening Integration Suite in BTP Cockpit?

Most often missing role collections or a stale session. Make sure your user has Integration_Provisioner and the PI_ role collections you need. Then close every BTP tab, sign out and sign back in, because new roles only apply after a fresh login.

If it persists, clear cookies for the BTP domains and keep to a single Cockpit session. Multiple tabs on the same subaccount trigger the same error.

Why does my CAP app fail to connect to a destination that appears correctly in the Cockpit?

Usually a naming mismatch. The destination name in cds.requires and in your xs-app.json routes must match the Cockpit exactly, including case.

If the name is right, check that the app is bound to both the Destination service and XSUAA, that the [production] profile carries the credentials, and that the kind matches the remote service: odata-v2 for V2, odata for V4. Use "Check Connection" in the Cockpit to confirm the target is reachable.

Why does my SAP BTP trial app stop working overnight?

On trial and free-tier plans, SAP HANA Cloud instances are stopped every night to save resources. Your app keeps running but cannot reach its database. Restart the instance in SAP HANA Cloud Central each day before you work.

Use cf apps and cf services to check memory and service usage, because trial quotas are hard to see in the Cockpit. Delete unused instances before creating new ones.

Why do links inside boosters and tiles lead to blank pages?

Booster links break when the subaccount structure changes after the booster ran. The redirect points to a location that no longer exists or was never fully configured.

Navigate through the Cockpit tree instead, and bookmark direct URLs for Integration Suite, destinations and SAP Build Work Zone. Do not rely on booster-generated navigation for anything you use daily.

When should I move from a BTP trial account to a paid plan?

When the limits start costing you time. If you run more than one app or database, or need stable uptime for demos or testing, the trial causes more friction than it saves.

The main gains are stability and clearer resource visibility, not new features. A productive account with free-tier plans is a good middle step: you can upgrade those plans to paid later without rebuilding anything.