Components
Each row is probed against the check stated underneath it. Bars run oldest to newest and end yesterday — today is still accruing and is not drawn.
Job board
OperationalThe Explore board, project pages, search and the matching service that decides which postings a contributor can see.
Measured against: Board search returns fresh results in under 800 ms at the 95th percentile.
Applications & assessments
OperationalApplication submission, credential upload, the timed assessment runner and assessment autosave.
Measured against: Assessment autosave acknowledged within 5 seconds; submissions accepted first try.
Work trials
OperationalTrial issuance, the trial workspace, submission upload and the two-reviewer scoring queue.
Measured against: Trial submissions accepted up to the 25 MB ceiling; scorecards issued inside 5 business days.
Time tracking
OperationalThe per-task timer, idle detection, manual time entries and the weekly hours ledger.
Measured against: Timer start and stop events persisted within 2 seconds and reconciled hourly.
Payouts
OperationalThe Friday payout run, instant payouts, statement generation and both settlement rails.
Measured against: Weekly run completes inside 45 minutes of 12:00 UTC Friday; instant payouts settle in about 30 minutes.
Authentication
OperationalSign-in, session issuance, authenticator-app codes, passkeys and recovery-code redemption.
Measured against: Sign-in succeeds within 3 seconds; valid second-factor codes accepted on first submission.
Public API
OperationalThe partner API used by lab customers for project intake, delivery pulls and quality reporting. Contributors are not affected by incidents here.
Measured against: Authenticated requests answered inside 500 ms at the 95th percentile, error rate under 0.1%.
Email delivery
OperationalSign-in links, verification mail, assessment results, payout statements and project notifications. The only support channel Cortext runs, so delivery failures are treated as customer-facing outages.
Measured against: Transactional mail accepted by the receiving server within 120 seconds of send.
Active incidents
Open incidents appear here first, within 30 minutes of detection, and are updated at least hourly until they close.
If something is broken for you while this page is green, it is specific to your account or your network. Retry in a private window with extensions disabled, then email support@cortext-ai.uk with the project name, the task or payout reference and the time in UTC.
Incident history
Every incident of the last 90 days, with the updates as they were posted and the retrospective written afterwards. Nothing is removed once posted, including the incidents caused by our own deploys.
Elevated sign-in latency during a database failover
A planned primary-database failover in the identity cluster took 12 minutes longer than the rehearsed time because a connection pool did not drain. Sign-ins succeeded throughout but took up to 9 seconds. Pool draining is now part of the pre-failover check and the rehearsal was repeated on 24 July with a 40-second cutover.
We are seeing elevated sign-in times following a scheduled database failover in the identity service. Sign-in is succeeding but slowly. No other component is affected.
The failover completed but a stale connection pool is still routing a share of requests to the former primary, which is now read-only. We are recycling the pool.
Pool recycled. Sign-in latency is back to normal at the 95th percentile. Watching for 15 minutes before closing.
Resolved. No sign-ins failed and no sessions were invalidated. Twelve minutes are counted against authentication uptime for the period where the check exceeded its threshold.
Weekly payout run delayed by 3h 41m
The settlement provider degraded its payout API at 12:02 UTC, four minutes into the weekly run, and returned 502s to roughly 60% of transfer requests for two hours. Cortext batches retries rather than firing them individually, which is why nothing double-paid, but the batch scheduler had no back-pressure and kept queueing until the provider recovered. 11,482 transfers were affected; all completed the same day. Two changes shipped on 22 July: the run now starts at 11:30 UTC to leave headroom before end of business in Europe, and the scheduler applies exponential back-off with a circuit breaker instead of a fixed retry cadence.
The weekly payout run started at 12:00 UTC and is failing a high share of transfer requests at our settlement provider. No payout has been lost and no transfer has been sent twice. We are investigating.
Our settlement provider has confirmed a degradation on their payout API affecting multiple customers. Approximately 60% of our transfer requests are returning 502. Transfers that already succeeded are unaffected and are arriving normally. The run is paused rather than retrying blindly.
Still paused. 4,116 of 15,598 transfers have settled. Contributors on the Wise rail are unaffected and those transfers have all completed. There is nothing to do on your side — do not resubmit payout details, and do not change your payout destination while the run is paused.
The provider reports recovery on their side. We are resuming the run in batches of 500 with verification between batches, which is slower than a normal run but avoids a second failure mid-flight.
All 15,598 transfers have been submitted and accepted. Standard arrival times are unchanged at 2–5 business days from submission. Instant payouts are re-enabled.
Resolved. Every payout in this run was submitted the same day. If your statement shows a released balance that has not arrived by 24 July, email payments with the payout reference and we will trace it. No fees were charged for instant payouts attempted during the incident window; those that failed were refunded automatically by 18 July.
Stale search results on the job board
A nightly search-index rebuild wrote to the wrong alias, so the board served an index that was 31 hours old. Postings opened after 02:00 UTC on 7 July were missing from search but reachable by direct link. The rebuild job now verifies the alias target before swapping and alerts if index age exceeds 90 minutes.
Contributors report that projects opened yesterday do not appear in board search. Direct links to those projects work. We are investigating the search index.
The overnight index rebuild published to a stale alias. Search is serving an index from 02:00 UTC on 7 July. Applications, assessments and all other components are unaffected.
A fresh index has been built and the alias corrected. Search results are current. We are watching index age for the next hour.
Resolved. No application was rejected or expired as a result — application windows are evaluated on the posting record, not on search visibility.
Work trial submissions above 10 MB failing
A storage-gateway configuration change reduced the multipart upload threshold from 25 MB to 10 MB without updating the client, so larger submissions failed after the progress bar reached 100%. 147 trial submissions were affected. Every affected trial had its deadline extended by 48 hours and no attempt was consumed. The gateway configuration is now asserted against the published 25 MB ceiling in CI.
We are investigating reports that work trial submissions with large attachments fail at the end of the upload. Smaller submissions are unaffected.
A storage gateway change rejected uploads above 10 MB while the tool still advertised the 25 MB ceiling. Your draft is cached in the browser — do not close the tab and do not restart the trial. We are rolling the change back.
Rollback complete and uploads up to 25 MB are succeeding again. If your submission failed, reopen the trial and submit the cached draft. Deadlines for affected trials have been extended by 48 hours automatically.
Resolved. 147 trials were affected; none consumed an attempt and none were scored on a partial submission. Contributors who abandoned a trial during the window have been contacted individually.
Delivery delays to Microsoft 365 and university domains
One IP in our transactional sending pool was rate-limited by a large receiving provider after a spike in verification mail during a recruiting push. Mail was queued, not lost, but sign-in links were arriving up to six hours late — long past their 30-minute validity — which made this an authentication problem as much as an email one. The sending pool is now split so that sign-in and payout mail never share an IP with bulk recruiting mail, and sign-in links are re-issuable without a new request.
We are investigating delayed delivery of verification and sign-in emails to some domains. Mail is queued rather than rejected. Contributors already signed in are not affected.
A sending IP in our transactional pool has been rate-limited by a major receiving provider. Delivery to Microsoft 365 and several university domains is delayed by up to six hours. We are moving transactional mail to a separate pool.
Transactional mail is now sending from the separate pool and new sign-in links are arriving normally. Mail queued before 10:00 UTC is still draining. If a sign-in link arrives expired, request a new one — the new request will use the healthy pool.
Queue is drained to under 400 messages, all of them low-priority notifications. Assessment result emails and payout statements sent during the window have been re-sent to affected recipients.
Resolved. No message was lost. Assessments that expired because a link arrived late have been reset without consuming an attempt; the contributors affected were emailed directly on 1 July.
Assessment autosave failures
A schema migration on the assessment store took a lock that blocked writes for reads-heavy sessions, so autosave silently failed while the editor reported success. 214 in-progress attempts were affected and up to 40 minutes of written work per attempt could not be recovered. Every affected attempt was voided and reissued with a fresh item set and no cost to the contributor's attempt count. Migrations against the assessment store are now restricted to the Thursday maintenance window and the editor surfaces an explicit warning when an autosave acknowledgement is missed.
We are investigating reports that assessment answers are not being saved. If you are mid-assessment, do not close the tab — copy your written answers to a local file before doing anything else.
A database migration is holding a lock on the assessment store and autosave writes are failing without surfacing an error. We have halted the migration. New assessment starts are blocked while we clear this.
The lock is released and writes are succeeding. We are identifying every attempt that lost data. Do not start a new attempt yet — attempts affected by this incident will be reissued and will not count against your three attempts.
214 affected attempts identified and voided. New assessment starts are re-enabled. Affected contributors are being emailed with a reissued assessment and a 14-day window to take it.
Resolved. If you were mid-assessment between 13:00 and 15:00 UTC and have not had a reissue email by 24 June, contact support with the project name and the time you started — the session log will confirm it.
Task timers not recording stop events
A deploy to the time service dropped the stop-event handler for tasks opened before the deploy, so timers kept running until the 6-minute idle timeout trimmed them. The effect was under-recorded time for contributors who submitted during the window, not over-billing. All affected time was reconstructed from session logs and credited before the pay week closed on 14 June, so no payout was short. Stop-event handling now has a contract test that runs against the previous release as well as the new one.
We are investigating reports that task timers continue running after a task is submitted. Tracked time may appear incorrect in the time tab.
A deploy 40 minutes ago dropped stop-event handling for sessions that predate it. Timers are being trimmed by the idle timeout, which means time is being under-recorded rather than over-recorded. Keep working; do not file time corrections yet, we will reconstruct the affected time centrally.
Fix deployed and stop events are recording normally. Reconstruction of affected time is running against the session logs.
Resolved. 6,241 task sessions were reconstructed and credited. This pay week closes on Sunday 14 June as normal and payouts release on Friday 19 June. If your time tab still looks wrong after 12 June, file a time correction and reference this incident.
Authenticator codes rejected after a secret-store rotation
A scheduled rotation of the key encrypting two-factor secrets re-encrypted the store but left one shard pointing at the retired key, so valid authenticator codes were rejected for about 9% of accounts with two-factor enabled. Passkey sign-in was unaffected throughout, which is the strongest argument for enrolling one. No recovery code was consumed by an account that was not genuinely locked out: redemptions during the window were reversed and re-issued on 28 May. Rotations are now staged shard by shard with a verification sign-in between each.
We are investigating reports that valid authenticator codes are being rejected at sign-in. If you have a passkey enrolled, use it — passkey sign-in is working normally. Do not spend your recovery codes yet.
A key rotation on the two-factor secret store left one shard reading a retired key. Roughly 9% of accounts with an authenticator app are affected. Existing sessions are unaffected; this only blocks new sign-ins.
We are re-encrypting the affected shard against the current key. This is deliberately slow — it verifies each record rather than bulk-writing — and we expect completion within 90 minutes. Recovery codes redeemed during this incident will be restored to your account afterwards.
Re-encryption complete. Authenticator codes are being accepted on all shards. We are monitoring sign-in success rates.
Resolved. Sign-in success is back to baseline. Recovery codes redeemed between 21:30 and 00:48 UTC have been reversed and fresh sets issued. No account required manual identity recovery as a result of this incident.
Public API returning 429 below quota
A rate-limiter configuration change applied per-key quotas as per-organisation quotas, so partners with several service keys were throttled at a fraction of their entitlement. Contributor-facing systems share no infrastructure with the partner API and were unaffected. The configuration is now generated from the entitlement record rather than maintained by hand.
Partners report HTTP 429 responses well below their contracted request quota. We are investigating. No contributor-facing component is affected.
A configuration change collapsed per-key quotas into a single per-organisation quota. Partners with multiple service keys are hitting the limit early. We are preparing a corrected configuration.
Corrected quotas are live in all regions and 429 rates have returned to baseline. Rejected requests were not billed.
Resolved. Delivery pulls queued during the window completed by 17:00 UTC and no project delivery deadline was missed.
Get told before you notice
One email when an incident opens, one when it closes, and one 72 hours before any maintenance that takes a component offline. Nothing else — this list is never used for anything but status.
Subscribe to status updates
Incident open, incident closed, and maintenance that takes a component offline. Roughly one email a month in a normal month, and none at all in a quiet one.
Email only — there is no SMS or webhook option, and status notifications are never used for recruiting or marketing.
What gets emailed regardless
Whether or not you subscribe here, contributors directly affected by an incident are emailed individually: a voided assessment attempt, a reconstructed timer session, a delayed payout, a re-issued statement.
Anything touching payouts, tax documents or contributor data is emailed even when the public impact was small enough that it never appeared on this page.
Status notifications go by email only. Cortext has no phone line, sends no SMS and will never ask you for a code. A text message about your Cortext account is phishing — forward it to security@cortext-ai.uk.
How uptime is measured
The figures above are worth exactly as much as the method behind them, so here is the method.