Skip to main content

Is Securly Down?

No — Securly is up

Reachable from all 8 checked regions

Average response time: 847ms

Last checked · checks run every 6 hours

Official status page: https://status.securly.com

Securly uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
996ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 19 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

19-day clean streak
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: 100.00% uptime, 15 checks
Aug 6: 100.00% uptime, 40 checks
Aug 7: 100.00% uptime, 32 checks
Aug 8: 100.00% uptime, 40 checks
Aug 9: 100.00% uptime, 31 checks
Aug 10: 100.00% uptime, 32 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 100.00% uptime, 32 checks
Aug 13: 100.00% uptime, 32 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 32 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 32 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 24 checks
Aug 20: 100.00% uptime, 40 checks
Aug 21: 100.00% uptime, 32 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 32 checks
Jul 25 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
977ms
DNS 0ms TCP 138ms TLS 281ms TTFB 700ms
arn
1177ms
DNS 0ms TCP 164ms TLS 337ms TTFB 672ms
bom
1577ms
DNS 0ms TCP 224ms TLS 450ms TTFB 902ms
cdg
1006ms
DNS 0ms TCP 143ms TLS 288ms TTFB 719ms
dfw
282ms
DNS 0ms TCP 39ms TLS 80ms TTFB 202ms
sin
1348ms
DNS 0ms TCP 191ms TLS 385ms TTFB 772ms
sjc
20ms
DNS 0ms TCP 1ms TLS 4ms TTFB 10ms
syd
1336ms
DNS 0ms TCP 190ms TLS 381ms TTFB 955ms
yyz
406ms
DNS 0ms TCP 57ms TLS 116ms TTFB 291ms

What Securly does

Securly filters web traffic and monitors student safety signals across school-managed devices, mostly Chromebooks. Districts run it as the layer every student request passes through, alongside classroom management, device management and hall pass tools. Because it sits in the request path, a Securly incident is felt by every student at once rather than by whoever happened to be using a particular feature.

What an outage looks like

Student devices lose web access entirely or hit filter blocks on sites that are normally allowed, because a filter that cannot reach its policy service tends to fail closed. Teachers find the classroom console will not load rosters or screens mid-lesson. Hall pass requests fail at the point a student needs one. Admin dashboards show stale device state, and safety alerting can lag without any visible error.

What to do about it

Check status.securly.com, which reports each region separately, including US East, a second US East, US West, UK and Canada, alongside Home, MDM, Classroom, Device Console, Aware, OnCall, Pass, Flex, Reveal, Rhithm and DyKnow Classroom. Identify your district's region before reading the banner. Have a documented lesson fallback that does not need student devices, since the practical impact lands on teachers in a live classroom rather than on IT.

Is it down for everyone, or just you?

If this page says Securly is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

P
PowerSchool
B
Blackboard
C
Canvas
Google Workspace
Google Workspace

Securly outage FAQ

Why did student devices lose internet when Securly went down?
A filtering layer generally fails closed rather than open, because allowing unfiltered student browsing is a worse outcome than allowing none. If devices cannot reach the policy service, requests are blocked instead of permitted. That is deliberate rather than a bug, and it is why a Securly incident presents to a classroom as no internet rather than as unfiltered internet.
Does the outage affect my district or all of them?
Possibly just yours. The status page reports US East, a second US East region, US West, UK and Canada as separate components, so an incident can be confined to one. Knowing which region your tenant sits in is the difference between reading the right line and assuming a global outage. The measurement above adds an independent view from several regions.
Can teachers keep teaching during a Securly outage?
Yes, if the fallback is prepared in advance. Classroom is its own component and can fail while devices still browse, or the reverse. A lesson that depends on live screen monitoring or pushed links stops; one built around printed or locally available material does not. Districts that circulate a short offline contingency to staff lose far less instructional time than those that improvise per incident.
Are safety alerts missed while Securly is down?
Alerting can be delayed by an incident affecting Aware or OnCall, which are listed as their own components. Delay is more common than loss, with signals arriving late rather than never. For the period of an incident, treat the absence of alerts as unknown rather than as an all-clear, and make sure the staff who normally act on them know the system was affected.
Should IT disable filtering to restore access?
That is a policy decision with compliance implications, not a routine remediation, and it is worth having decided before an incident rather than during one. Districts operating under filtering requirements may not be able to disable it at all. If it is on the table, agree in advance who authorises it and how it gets re-enabled, because the re-enable step is the one that gets forgotten.

How we measure this

  • We request Securly's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Securly publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Securly goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required