SLA, uptime, and the checking procedure during an incident

Uptime targets

Status page

ReceiptRoller publishes its operational status on a public status page.

https://status.receiptroller.io

• API, Webhook, authorization, developer portal, and each SNS integration are shown separately
• You can see the incident history for the past 90 days
• You can subscribe via RSS / Webhook / email

We recommend production teams build this page into their monitoring dashboard.

Isolation procedure when an incident occurs

Step 1: Isolate whether it is your side or external

1. Are your other features working?
2. Is there no incident for the relevant feature on ReceiptRoller's status page?
3. Whether there was a recent deploy on your side

Step 2: When a ReceiptRoller-side incident is suspected

1. Check the status page
2. Note the X-RR-Request-Id of requests from the past 5 minutes
3. Note the contents of the error response (HTTP status, code, message)
4. Check the scope of impact (all requests failing / some failing / only a specific endpoint)

Step 3: When your own environment is suspected

1. Consider rolling back a recent deploy
2. Are the environment variables / secrets correct?
3. Network, DNS, TLS certificate
4. The state of downstream DBs, caches, and external APIs

Support escalation

Minor (can be isolated on your side)

Post to the developer community. You may also get insight from other developers.

Medium (cannot identify the cause on your side)

Email the support desk. Always include the following information.

• App ID (client ID)
• The time range when the issue occurred (state UTC or JST explicitly)
• The affected API endpoints and HTTP methods
• Several request_ids
• The contents of the error response
• What you checked on your side

Critical (large production impact)

Plans of Growth or higher have an emergency support desk. Enterprise gets a dedicated Slack channel, etc.

What happens when the SLA is not met

On plans of Growth or higher, if the monthly uptime falls below the SLA, we refund a portion of the following month's fee (as a credit). See your contract for details.

Notification of planned maintenance

• As a rule, rolling deploys with no impact
• For large-scale changes, we notify at least 14 days in advance
• Notifications go out via the status page, developer portal announcements, and email

Related guides

• Best practices for production operation
• Monitoring and handling failures
• Posting a question to the community
• Back to the developer help index