Skip to main content

User Manual

This manual covers every feature of the KredSLA platform in detail. If you haven't set up your account yet, start with the Getting Started guide.

Dashboard​

The dashboard is your command center for SLA credit recovery. It provides a real-time overview of your cloud credit recovery activity.

Savings Widget​

The savings panel shows:

  • Total credits recovered — lifetime amount recovered across all providers
  • Monthly recovery trend — line chart tracking credits over time
  • Recovery by cloud provider — breakdown showing which providers contribute the most credits
  • Credit distribution — how recovered value is distributed across services and regions

Claims Tracker​

The claims table gives you full lifecycle visibility into every SLA claim:

ColumnDescription
StatusCurrent claim state (Detected → Bundled → Filed → Approved/Rejected)
ProviderAWS, Azure, GCP, or OCI
ServiceThe affected cloud service (e.g., EC2, RDS, Cloud SQL)
AmountEstimated or confirmed credit amount
DetectedWhen the SLA breach was first identified
FiledWhen the claim was submitted to the provider
ResolvedWhen the provider issued a decision

You can sort and filter claims by provider, status, service, date range, and amount.

Claim Statuses​

StatusMeaning
DetectedAn SLA breach has been identified and verified against the provider health feed
BundledEvidence (metrics, incident records, dependency analysis) has been compiled
FiledA support case has been submitted to the cloud provider
ApprovedThe provider has approved the credit
ReconciledThe credit has appeared on your billing statement
RejectedThe provider denied the claim

Cloud Account Management​

Connecting Cloud Accounts​

Navigate to the Cloud Accounts section to manage your provider connections. See the Getting Started guide for initial setup instructions.

Account Statuses​

StatusMeaning
ActiveAccount is connected and resources are being monitored
ScanningInitial resource discovery is in progress
ErrorCredential issue or connection problem — check your IAM role/service principal
RevokedYou've disconnected this account

Resource Discovery​

When you connect a cloud account, KredSLA runs an automated discovery scan that:

  1. Enumerates all SLA-eligible resources using the provider's SDK
  2. Maps each resource to the applicable SLA definition from the SLA Library
  3. Builds a service dependency graph to trace outages to their root cause
  4. Marks the account as Active when complete

You can trigger a re-scan at any time by clicking Rescan on a connected account.

Supported Services​

KredSLA monitors the top services across each provider:

RankAWSAzureGCPOCI
1EC2Virtual MachinesCompute EngineCompute
2RDSAzure SQL DatabaseCloud SQLAutonomous Database
3S3Blob StorageCloud StorageObject Storage
4LambdaApp ServiceCloud FunctionsFunctions
5EBSManaged DisksPersistent DiskBlock Volume
6DynamoDBCosmos DBCloud SpannerNoSQL Database
7Route 53Azure DNSCloud DNSDNS
8ELB/ALBLoad BalancerCloud Load BalancingLoad Balancing
9CloudFrontAzure Front DoorCloud CDNData Transfer
10RedshiftSynapse AnalyticsBigQueryAutonomous Data Warehouse

Observability Bridge​

The Observability Bridge connects KredSLA to your monitoring tools for richer SLA breach detection.

Supported Platforms​

PlatformHow to ConnectWhat It Provides
CloudWatchAuto-discovered via AWS accountAvailability metrics, health checks
Azure MonitorAuto-discovered via Azure accountService availability, heartbeat data
GCP MonitoringAuto-discovered via GCP accountUptime check results
OCI MonitoringAuto-discovered via OCI accountResource availability metrics

Mapping Observability to Cloud Accounts​

Each observability integration can be linked to one or more cloud accounts. This allows KredSLA to correlate provider-side incidents with your own monitoring data for stronger evidence in credit claims.

SLA Library​

The SLA Library is a read-only reference of cloud provider SLA definitions. Each entry includes:

  • Provider and service name
  • Guaranteed uptime percentage (e.g., 99.99%)
  • Credit tiers — what percentage credit you receive for different levels of downtime
  • Filing requirements — deadlines and evidence needed for claims
  • Filing window — how long you have to submit a claim after an incident

Filing Deadlines by Provider​

ProviderFiling Window
AWSEnd of the second billing cycle after the incident
AzureWithin two months of the end of the billing month
GCPWithin 30 days of the incident
OCIPer service-specific terms

KredSLA tracks these deadlines automatically and ensures claims are filed well within the window.

How SLA Breach Detection Works​

KredSLA's automated detection pipeline runs continuously:

1. Metric Collection (Every 30 Minutes)​

Availability metrics are pulled from your connected observability platforms:

  • Cloud-native monitoring (CloudWatch, Azure Monitor, GCP Monitoring, OCI Monitoring)

2. Breach Detection​

If availability drops below the provider's SLA target (e.g., below 99.99% monthly uptime):

  • The system cross-references the incident with the provider's official health feed (AWS Health, Azure Service Health, GCP Status, OCI Status)
  • Only provider-acknowledged incidents are considered — this ensures claims have a high approval rate

3. Root Cause Analysis​

KredSLA walks the service dependency graph to trace the outage to its root managed-service failure. This determines:

  • Which high-level service was affected
  • Whether the root cause was a provider-managed service (eligible for credit) or customer-managed

4. Evidence Bundling (Every 10 Minutes)​

For each detected breach, an evidence package is assembled:

  • Availability metrics with precise timestamps
  • Provider health incident records
  • Dependency path showing the root cause
  • Applicable SLA definition and credit tier

5. Claim Filing (Every Hour)​

Bundled claims are submitted to the cloud provider via their support API:

  • AWS — via AWS Support API (CreateCase)
  • Azure — via Azure Support SDK
  • GCP — via Cloud Support API
  • OCI — via OCI Support API

6. Status Tracking (Every 6 Hours)​

Filed claims are polled for status updates. The claim moves to Approved or Rejected based on the provider's response.

Billing & Subscription​

Navigate to Billing Settings to manage your subscription and payment.

Pricing Model​

KredSLA uses a contingency-based model — you only pay when credits are successfully recovered:

  • Contingency fee: A percentage of recovered credits (default 20%, configurable per organization)
  • No recovery, no fee — if KredSLA doesn't recover credits, you pay nothing

Billing Cycle​

  • Fees are calculated monthly based on credits approved during the billing period
  • Invoices are processed via Stripe
  • Payment terms: Net 30 from invoice date

Authentication & Security​

Supported Login Methods​

MethodDetails
Google WorkspaceOAuth 2.0
Microsoft Entra IDOAuth 2.0 (supports multi-tenant)
OktaOIDC or SAML
JumpCloudOIDC or SAML
Email + PasswordWith 2FA via email code

Two-Factor Authentication (2FA)​

For email/password logins, KredSLA requires a one-time code sent to your registered email address. Codes expire after a short window and cannot be reused.

Session Security​

  • JWT tokens are issued with a 1-hour TTL
  • Tokens include issuer (kredsla) and audience (kredsla-api) claims
  • Authentication endpoints are rate-limited to 5 requests per minute
  • Sessions use HTTPS-only cookies in production

Credential Security​

  • All cloud provider credentials are stored in OpenBao (open-source Vault), never in the database
  • The database stores only a vault reference path
  • Credentials are fetched at task execution time and never cached
  • When an account is deleted, credentials are immediately purged from the vault

Organization Settings​

Account Deletion​

You can delete your organization and all associated data at any time. Deletion is immediate and cascading:

  1. All organization records are removed from the database
  2. Cloud credentials are purged from the vault
  3. Redis cache entries are cleared
  4. An audit event is logged for compliance
  5. Backup data is purged within 30 days via snapshot rotation

This process complies with GDPR Article 17 (Right to Erasure).

Data Retention​

Data TypeHow Long It's Kept
Active account dataWhile your account is active
Cloud credentialsWhile your account is active (purged on deletion)
SLA claim records7 years after resolution (financial compliance)
Auth event logs1 year (security monitoring)
Redis cache15 min – 1 hour (auto-expires)

Audit Logging​

KredSLA maintains comprehensive audit logs for compliance and transparency:

  • Authentication events — logins, SSO flows, 2FA verifications, failed attempts
  • Claim lifecycle events — detection, evidence bundling, filing, approval, rejection
  • Account events — creation, deletion, settings changes

All logs are structured JSON, ready for export to your log aggregation platform (CloudWatch, Datadog, etc.).

Troubleshooting​

Cloud Account Won't Connect​

  • Verify the IAM role/service principal has the required permissions
  • Ensure the credentials haven't expired or been rotated
  • Check that the role trust policy allows KredSLA's account ID
  • Try disconnecting and reconnecting the account

No SLA Breaches Detected​

This is often a good sign — your cloud providers are meeting their SLA commitments. KredSLA monitors continuously, and breaches will appear as soon as they're detected and verified against the provider health feed.

Claim Was Rejected​

Cloud providers may reject claims for several reasons:

  • The incident didn't meet the SLA breach threshold
  • The affected service wasn't covered by the specific SLA terms
  • The root cause was attributed to customer-managed infrastructure

Rejection details are available in the Claims Tracker.

Login Issues​

  • "OAuth provider not configured" — Contact your administrator to configure SSO
  • "Redirect URI mismatch" — The SSO redirect URI needs updating in your identity provider
  • 2FA code not received — Check spam folders; codes expire after a few minutes

Need Help?​