Common Status Codes
- 401 Unauthorized
- The API did not accept the request as authenticated. Check the tile auth profile, token URL, Keycloak realm, client id/secret, and whether the deployed API expects a different auth server.
- 403 Forbidden
- The token was accepted, but the service account does not have the required role. Add the expected realm role, such as
db_read or file_read, to the scanner service account in the API's realm.
- 404 Not Found
- The server responded, but the endpoint path was not found. Check the IIS application folder plus controller route, for example
Folder/Controller/corecheck.
- 500 Server Error
- The endpoint was found, but the application failed. Check the app pool, .NET hosting bundle/runtime, appsettings environment, database access, logs, and missing files.
Reading CoreCheck Results
Hover over a tile for a compact summary of the latest result. The ... prompt means additional response data is available. Click the tile to open the complete latest CoreCheck response in a formatted details rail; nested runtime, security, route, and dependency data can be expanded as needed.
While an Alert Group is being edited, clicking a tile continues to add or remove that target from the group instead of opening response details.
Access
Use Keycloak sign-in for normal dashboard use. The browser uses Authorization Code with PKCE, so no client secret is used for human login. The developer service-account token section is for testing backend/API access and does not store the client secret.
Role-limited CoreCheck API access is enforced for protected actions. Dashboard viewing is public; scanning requires corecheck.operator or corecheck.admin, and target/auth-profile changes require corecheck.config or corecheck.admin.
The CoreCheck API status endpoint is protected because it returns operational metadata for DevOps troubleshooting. If you are signed out, the dashboard can still show saved monitoring data, but the top API status pill asks you to sign in before showing API status.
Alert Tests
The Alert Test box sends one direct SMS through CoreCheck API and AICORE.SMS. The Event-SMS Test box publishes an AICORE.Events message from CoreCheck API to the aicore.events topic exchange with routing key corecheck.alert.detected; consumers such as SMS own their queues and bindings.
Alert Test
The left rail alert test sends one manual SMS through CoreCheck API to AICORE.SMS. Use it to confirm that CoreCheck can reach the SMS module before automatic alerting is enabled.
Select an encrypted Auth Profile for the SMS service account, enter the SMS sender profile, recipient, and message, then send the test. The browser does not call AICORE.SMS directly.
Expired Sign-In
When a Keycloak token expires, CoreCheck leaves the dashboard visible but disables scan, edit, reset, alert group, auth profile, and test SMS actions. Sign in again to continue operating the dashboard.
If the user is active on the page, CoreCheck automatically tries to renew the sign-in when the token has 2 minutes or less remaining. If renewal fails or the page has been idle for more than 10 minutes, protected actions stay disabled until the user signs in again.
Alert Groups
Alert Groups define which targets should notify an operator when health state changes. Select a group in the left rail, then click tiles to add or remove them from that group. Member tiles show a green alert-group marker.
Use the Configure Alert Group rail to update automatic SMS event publishing, test delivery, or ownership hints.
When editing a selected Alert Group, click dashboard tiles to add or remove members.
Automatic SMS has two separate trust steps. CoreCheck must be allowed to call AICORE.SMS, and AICORE.SMS must be allowed to call the external SMS provider such as Twilio, Voip.ms, or AWS SNS.
The SMS Auth Profile is the CoreCheck-to-AICORE.SMS credential. CoreCheck uses it server-side to get an access token before asking AICORE.SMS to send or process an alert message.
The SMS Provider Profile selects the provider credentials managed by AICORE.SMS. Those credentials are not stored in this dashboard; they belong to the SMS application because it is the system that talks to Twilio, Voip.ms, AWS SNS, or another provider.
Automatic notifications use AICORE.Events. When an enabled member target changes from green to action needed, or from action needed back to green, CoreCheck records the alert event in SQL and publishes it to aicore.events with routing key corecheck.alert.detected. AICORE.SMS consumes that event, applies the selected provider profile, and sends the text message.
Select Enable Automatic SMS on the group, then set the SMS auth profile, SMS provider profile, recipient, and message template. Existing groups are not automatically enabled after upgrades, to avoid surprise SMS alerts.
Use Test Event on a selected group to publish an AICORE.Events message with that group's SMS provider, recipient, and template. Use Send Direct Test SMS inside Configure only as a troubleshooting fallback when you want to prove AICORE.SMS accepts the same message without AICORE.Events.
Message templates can use {{serverName}}, {{apiName}}, {{endpointPath}}, {{previousState}}, {{newState}}, {{statusCode}}, and {{checkedAt}}.
Database Model
CoreCheck v2 uses one central SQL Server database right now. The active database lives on products.coredata.ca, and additional CoreCheck API deployments connect back to it.
For this stage, products.coredata.ca and aicoredev2.coredata.ca show the same source-of-truth records. Remote SQL access is restricted by firewall rules and uses a SQL login stored as server configuration, not in the web code.
Scan, Refresh, and Automation
- Refresh
- Reloads the latest saved dashboard data from CoreCheck API. It does not call the monitored APIs.
- Scan Now
- Asks CoreCheck API to call enabled corecheck endpoints and save new results to SQL.
- Scheduled scans
- The active scheduler runs from the primary products deployment every 5 minutes. It performs a full scan of enabled targets every 30 minutes. Secondary deployments can display and edit data, but should not run a scheduler until scan locking is implemented.
- Retry behavior
- Green targets wait for the 30-minute macro cycle. Failed targets are retried every 5 minutes, with a 60-second delay between failed checks on the same server to reduce pressure during outages.
Stage-1 Uptime
The uptime and downtime values on each server bar are simple accumulators for now. They are not yet calculated from a complete scan history.
When the scheduled 30-minute full scan sees every enabled tile on a server green, CoreCheck adds 30 minutes to that server's uptime. When the 5-minute retry scan still finds action-needed tiles on a server, CoreCheck adds 5 minutes to downtime. Counters since shows the start of the current accumulator window. Reset clears both counters for that server and moves that start time to the reset time.