Passing
Sign-in page & app script
Can the public sign-in page and its application code be loaded?
Passed394 ms
Service status & availability
PineKey service status.
Our target is 99.5% monthly availability. See the checks, their coverage and the history behind the number.
This month · 2026-1199.97%Above the 99.5% target · 1 failed minutes
Today · 2026-11-03100.00%0 failed minutes
Last month · 2026-10Not verified99.87% observed · 87.68% measured
Self-managed checks every minute, from two locations. See what the figures cover. Last verified backup: 2026-11-03 01:33:13 UTC. Standby server: ready.
01 / Recorded history
Daily history
No failuresBrief interruptions, above targetBelow targetToo little measured
Up to 90 days · select a day for its measurements. Each day is compared with the 99.5% target. Striped days have measurements for less than 99% of their minutes.
2026-09-182026-11-03
2026-11-03: 100.000% observed availability · 0 failed · 0 unknown · 794 elapsed minutes.
02 / Service checks
Every minute · public HTTPSWhat we check
Two checks follow the path your browser uses. Each must pass for the service to show as available.
Passing
API & database readiness
Can the application reach the vault backend and its database?
Passed218 ms
Monthly reports
UTC calendar months. A completed month is marked Met only when the entire month was monitored, coverage is complete and availability reached 99.5%. This month so far 99.809%–99.973% depending on the 6 unmeasured minutes.
| Month | Observed | Coverage | Failed minutes | Unknown minutes | Result |
|---|---|---|---|---|---|
| 2026-11 | 99.973% | 99.837% | 1 | 6 | In progress |
| 2026-10 | 99.875% | 87.679% | 49 | 5500 | Unverified |
| 2026-09Partial month | 99.588% | 18.786% | 14 | 14707 | Unverified |
Detected interruptions
The 20 most recent groups of consecutive failed minute checks within 90 days. Gaps in monitoring split a group; these are measured failure windows. Where we know more, our note follows the window.
- 2026-11-01 06:24:00 UTC – 2026-11-01 06:25:00 UTC1 failed minute checks
- 2026-10-30 19:29:00 UTC – 2026-10-30 19:30:00 UTC1 failed minute checks
- 2026-10-29 20:23:00 UTC – 2026-10-29 20:24:00 UTC1 failed minute checks
Planned Planned drill: moving the service to the standby and back
We moved PineKey to its standby server in Sweden and back again to test the takeover. The service was unreachable for about 47 seconds on the way over and about 30 seconds on the way back. No data was lost.
- 2026-10-29 19:08:00 UTC – 2026-10-29 19:09:00 UTC1 failed minute checks
- 2026-10-27 09:42:00 UTC – 2026-10-27 09:44:00 UTC2 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 09:05:00 UTC – 2026-10-27 09:06:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 09:03:00 UTC – 2026-10-27 09:04:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 09:01:00 UTC – 2026-10-27 09:02:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 08:53:00 UTC – 2026-10-27 08:54:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 08:50:00 UTC – 2026-10-27 08:51:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-27 08:48:00 UTC – 2026-10-27 08:49:00 UTC1 failed minute checks
Degraded Slow responses
In eight separate minutes the sign-in page took longer than ten seconds to load, while the API answered but slowly. The server itself was almost idle at the time, so the delay was on the way between visitors and the server. We have not found the exact cause.
- 2026-10-24 18:02:00 UTC – 2026-10-24 18:03:00 UTC1 failed minute checks
- 2026-10-23 10:36:00 UTC – 2026-10-23 10:37:00 UTC1 failed minute checks
- 2026-10-23 03:51:00 UTC – 2026-10-23 03:52:00 UTC1 failed minute checks
- 2026-10-22 12:20:00 UTC – 2026-10-22 12:21:00 UTC1 failed minute checks
- 2026-10-21 22:43:00 UTC – 2026-10-21 22:44:00 UTC1 failed minute checks
- 2026-10-21 22:02:00 UTC – 2026-10-21 22:17:00 UTC15 failed minute checks
Incident PineKey could not be reached
PineKey could not be reached for 15 minutes. The server and its services kept running and outgoing mail worked; the fault was between the server and visitors, most likely in the connection through our delivery network. We have not found the exact cause.
- 2026-10-17 00:08:00 UTC – 2026-10-17 00:09:00 UTC1 failed minute checks
- 2026-10-15 18:11:00 UTC – 2026-10-15 18:12:00 UTC1 failed minute checks
- 2026-10-15 15:05:00 UTC – 2026-10-15 15:06:00 UTC1 failed minute checks
How availability is measured
- Correction, 4 October 2026. From 18 September to 4 October the sign-in check failed because of a fault in the monitor, not in the service: it looked for text the page no longer renders before it loads. Those minutes are shown as unmeasured rather than as failures. API and database checks from the same period are unchanged.
- One scheduled check per minute from our own monitoring service. It calls the public HTTPS sign-in and readiness endpoints, including the delivery network and tunnel, and saves results in its own database. A second measuring point in Sweden runs the same checks; a minute the first one could not record is filled from the second when it has one. It counts only minutes in which it could reach the internet itself.
- Both the sign-in page with an application script and API/database readiness must pass within ten seconds per check. Redirects, unexpected content, stale readiness responses and timeouts fail the check. Failures are not hidden by retries.
- Observed availability = successful minutes ÷ recorded minutes. Coverage = recorded minutes ÷ expected minutes. Confirmed availability divides successful minutes by all expected minutes. Missing measurements are shown separately as unknown.
- Planned maintenance, deployments and delivery-provider failures count. Minutes neither point measured are never backfilled. The first month is explicitly partial. Raw records are kept for 400 days; this page shows 90 daily and up to 12 monthly reports.
- The main monitor runs on the same server as PineKey. If that server stops, live status returns when it or the standby server is running; the second point’s minutes are added then. Both points are ours: this is self-monitoring, not an independent external measurement.
- One-minute sampling estimates reachability; it does not test every sign-in, vault operation, email delivery or browser interaction, and it may miss shorter interruptions.
Measurement started: 2026-09-18 10:11:00 UTC. Reports refresh every minute; readings more than 150 seconds old are marked unknown.
Read the service levels and closure commitment. At least three calendar months’ notice, never less than 90 days, before planned permanent closure.