System Status
API Status
Live status for all ibanchecker.cash API endpoints. Every number on this page is measured by automated checks against the production API; nothing is estimated.
Monitoring data is being collected
Automated checks run every 5 minutes. First results will appear shortly.
Overall uptime · last 90 days
IBAN Validation
POST /api/v1/validate
Collecting data
—
Bulk Validation
POST /api/v1/validate/bulk
Collecting data
—
IBAN Extractor
POST /api/v1/extract
Collecting data
—
IBAN Formats
GET /api/v1/formats/[country]
Collecting data
—
BIC / SWIFT Lookup
GET /api/v1/swift/[bic]
Collecting data
—
Automated checks run every 5 minutes from Cloudflare’s network against the live production API. Each bar represents one calendar day; uptime is computed from every recorded check in that day. We publish measured values only, going back up to 90 days.
Declared Status
All systems operational
Operational · machine readable at /status/status.json · Atom feed
Planned Maintenance
None scheduled. We do not take planned downtime: the site and the API are deployed to Cloudflare’s edge, releases are atomic, and a new version replaces the old one without a window in which requests fail. If that ever changes, the window will be announced here and in the feed before it starts.
Incident History
- Resolved
All API endpoints returned 404 for about eight minutes
15:45 to 15:53 UTC · 8 minutes · major impact · all five API endpoints
- investigating
A deploy went out at 15:45 UTC. Every /api/v1 endpoint began answering 404, and POST requests answered 405. The website itself was unaffected and kept serving normally.
- resolved
Cause: that release added prerendered files under /api. Cloudflare Pages serves static assets before the Worker, so the whole /api prefix resolved as static and the dynamic API routes were never reached. Moving those files out of /api restored the API at 15:53 UTC, and all five endpoints were checked by hand afterwards. The window is bounded by the two deployment timestamps, so treat it as eight minutes give or take a minute.
- postmortem
Worth stating plainly: our own monitor did not catch this. It counted a check as failed only on a server error or a timeout, so a 404 read as a healthy answer and the uptime figures for the day show no failures. That is a gap in the measurement, not a quiet outage. The monitor now checks that each endpoint returns the response it is supposed to return, so a routing failure of this kind counts as downtime from here on.
How We Measure Uptime
Every figure on this page is produced the same way, with no manual edits. Here is the exact method, so you can judge the numbers for yourself rather than taking our word for it.
What we check
Five production API endpoints are probed every 5 minutes, around the clock, from Cloudflare's global network. That is 288 checks per endpoint per day, run by an independent monitor, not by the API itself.
What counts as a failure
A check fails only if the endpoint returns a server error (HTTP 5xx) or does not respond within 10 seconds. Client responses such as a 429 rate limit are not treated as downtime, because the service is answering correctly.
How the percentage is calculated
Uptime equals successful checks divided by total checks across the selected window, rounded to two decimals. We apply no smoothing, no weighting, and no minimum-failure threshold. It is the strictest honest reading of the data.
How each day is coloured
Operational. Every check that day succeeded.
Degraded. At least one check failed, but the endpoint stayed reachable. We do not hide a single failed check. A lone transient blip, for example a momentary edge hiccup during a deployment, turns the whole day amber on purpose.
Outage. Every check in an interval failed, meaning the endpoint was genuinely unreachable.
No data. The day falls before automated monitoring began. We never back-fill or estimate it.
Standards & Independent Assurance
Availability is a recognised reliability measure with formal definitions on both sides of the Atlantic. Our method follows the same definition those frameworks use.
SOC 2 Type II (AICPA, United States)
Availability is one of the AICPA Trust Services Criteria: the system should be available for operation and use as committed. Our uptime figure measures exactly that.
ISO/IEC 27001:2022 and C5:2020 (BSI, Germany)
Availability is one of the three pillars of information security, alongside confidentiality and integrity, in the international ISO standard and Germany’s federal C5 cloud catalogue.
To be precise about what is certified: we do not claim our own SOC 2 or ISO certificate. The API runs entirely on Cloudflare, which is independently audited against SOC 2 Type II (Security, Confidentiality and Availability), ISO/IEC 27001:2022, ISO/IEC 27018, C5:2020 and PCI DSS 4.0. Those audits cover the infrastructure this service depends on. You can review them on Cloudflare’s compliance hub. For how we verify our IBAN and bank data, see our data methodology.
Availability Commitments
Infrastructure uptime SLA (Cloudflare)
Edge locations globally
Automated check interval
Published uptime history
Contractual SLAs with service credits apply to Growth (99.9%) and Enterprise (99.99%) plans. Contact us for SLA details.