Skip to content
Pikorua Security

System status

Pikorua Security system status

Live health for every part of Pikorua Security, checked every 60 seconds from AWS us-east-1 and us-west-2. Incident history and postmortems cover the last 90 days.

Current status

All systems operational

Components
10 of 10 operational
Active incidents
None
Last incident
September 9, 2026, resolved
Next maintenance
October 25, 2026

Components

Hover or focus a bar to see that day. Times in UTC.

Core platform

  • Web app

    Dashboard, vendor records, rule builder and audit vault

    100%Operational

    90 days agoOct 15, 2026

  • Parsing pipeline

    ACORD 25, ACORD 28 and endorsement page extraction

    99.97%Operational

    90 days agoOct 15, 2026

  • Endorsement engine

    Form, edition, limit and AM Best checks against contract rules

    99.98%Operational

    90 days agoOct 15, 2026

  • API

    REST API and outbound webhooks

    100%Operational

    90 days agoOct 15, 2026

Notifications

  • Broker email delivery

    Deficiency notices, renewal reminders and upload links

    100%Operational

    90 days agoOct 15, 2026

  • SMS

    Text reminders to vendors and site supervisors

    100%Operational

    90 days agoOct 15, 2026

Integrations

  • Procore sync

    Compliance status and payment holds on commitments

    99.96%Operational

    90 days agoOct 15, 2026

  • Yardi sync

    Vendor status and AP holds in Yardi Voyager

    100%Operational

    90 days agoOct 15, 2026

  • AppFolio sync

    Vendor compliance and insurance expiration dates

    100%Operational

    90 days agoOct 15, 2026

  • Access control webhooks

    Badge suspend and restore events for jobsite access systems

    100%Operational

    90 days agoOct 15, 2026

No incidents Degraded performance Outage
Web app uptime over the last 90 days
100%
Web app uptime over the last 90 days
Measured every 60 seconds
Lowest component uptime (Procore sync) over 90 days
99.96%
Lowest component uptime (Procore sync) over 90 days
Degraded minutes counted as downtime
Incidents in 90 days, both minor, both with published postmortems
2
Incidents in 90 days, both minor, both with published postmortems
3 component-days affected
Typical time from upload to a verified result for a full endorsement packet
~15 sec
Typical time from upload to a verified result for a full endorsement packet
Parsing pipeline target

Scheduled maintenance

Database minor version upgrade

Sunday, October 25, 2026, 06:00 to 06:30 UTC (2:00 to 2:30 am Eastern)

The web app will be read-only for up to 10 minutes while the primary database fails over. Uploads, broker emails and integration events received during the window are queued and processed afterwards. No action is needed.

Scheduled

Subscribe to updates

Get incident and maintenance emails

Pick the components your team depends on. We email when an incident opens, at each update, when it resolves, and 72 hours before maintenance.

Components

Incident history

Past incidents and postmortems

Every incident gets a written postmortem within five business days: what happened, who was affected, why, and what we changed.

  1. , 16:31 to 17:18 UTC (47 minutes)

    Delayed compliance status sync to Procore

    Procore sync

    MinorResolved

    1. 16:31 UTC · Investigating

      Compliance status changes are reaching Procore later than normal. Status inside Pikorua Security is current. We are investigating.

    2. 16:48 UTC · Identified

      A historical backfill for a newly connected company used up the API request budget shared with live status writes. We have paused the backfill.

    3. 17:02 UTC · Monitoring

      Queued status writes are draining. All queued changes are expected in Procore within 15 minutes.

    4. 17:18 UTC · Resolved

      All queued status changes have been written to Procore. Hold and release history is complete.

    Read the postmortem

    Summary

    For 47 minutes, compliance status changes reached Procore late because a backfill job and live status writes shared one API request budget.

    Customer impact

    Status changes for 27 vendors across 9 customer companies were delayed by up to 47 minutes. No status was written incorrectly and no data was lost. Two invoices were approved in Procore during the window for vendors whose status had just moved to deficient; we contacted both customers directly with the invoice details the same afternoon.

    Root cause

    When a new company connects, Pikorua Security backfills compliance status for its existing vendors. Backfills and live status changes drew from the same hourly request budget. A large backfill exhausted it, and live writes queued behind it until the budget reset.

    What we changed

    • Backfills now run in a separate, capped lane; live status changes always have reserved capacity.
    • Queued live writes older than 5 minutes page the integrations on-call engineer.
    • The integration health panel now shows customers any vendor whose Procore status is waiting to sync.

  2. , 14:02 to 14:40 UTC (38 minutes)

    Slow verification of multi-page endorsement packets

    Parsing pipelineEndorsement engine

    MinorResolved

    1. 14:02 UTC · Investigating

      Multi-page endorsement packets are taking longer than usual to verify. Single-page certificates are unaffected.

    2. 14:19 UTC · Identified

      Extraction workers did not scale out quickly enough after a large bulk import. We have added capacity manually.

    3. 14:31 UTC · Monitoring

      The backlog is clearing and new packets are verifying at normal speed.

    4. 14:40 UTC · Resolved

      All delayed packets have been processed. Results were not affected, only timing.

    Read the postmortem

    Summary

    For 38 minutes, multi-page endorsement packets took several minutes to verify instead of about 15 seconds, because extraction capacity scaled out too slowly after a bulk import.

    Customer impact

    1,912 packets were delayed, with a median delay of 11 minutes and a maximum of 26 minutes. Verification results were unaffected. Deficiency notices for those packets went out after processing completed.

    Root cause

    A customer imported several thousand renewal packets at once. Our autoscaling watched queue depth averaged over 10 minutes, so it added extraction workers well after the queue had grown, and new workers needed time to load models.

    What we changed

    • Autoscaling now reacts to the age of the oldest queued packet, not average depth.
    • A warm pool of extraction workers stays loaded during US business hours.
    • Bulk imports above 500 packets are throttled per customer so interactive uploads stay fast.

No other incidents in the last 90 days. Older postmortems are available to customers in the Trust Center.

SecuritySOC 2 Type II, encryption and access controls.Trust CenterReports, policies and subprocessors.Report a problemCall 1800-425-0619 (24x5) or contact support.